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# Público-alvo 


A indústria de jogos parece ter uma resisténcia aos métodos ágeis. 
Entretanto, grande parte dessa resisténcia se dá por tentativas 
frustradas de tentar implementar algumas ferramentas propostas 
pelos métodos ágeis. Sempre creio que os métodos e ferramentas 
ágeis aplicadas não podem nunca sobrepor o que o manifesto ágil 
(http://agilemanifesto.org/iso/ptbr/manifesto.html) propõe: 


e Indivíduos e interações mais que processos e ferramentas. 

e Software em funcionamento mais que documentação 
abrangente. 

e Colaboração com o cliente mais que negociação de contratos. 

e Responder a mudanças mais que seguir um plano. 


O que mais percebo é o peso que o primeiro item tem, pois 
raramente vejo um local em que processos e ferramentas não sejam 
superiores a indivíduos e interações. Sempre que vejo empresas de 
jogos falando de suas tentativas frustradas com métodos ágeis, 
vejo-os falando como utilizaram os processos e a ferramenta de 
forma rígida, o que me dá muita pena. 


Além disso, creio que o desenvolvimento guiado por testes tenha 
nascido do segundo item, já que, ao meu ver, testes extensivos 
podem ser interpretados como documentação, e ainda ajudam no 
software em funcionamento. Penso que, no mundo dos jogos, a 
colaboração com o cliente seja a etapa fundamental no 
desenvolvimento, já que o software serve, principalmente, para o 
entretenimento. Outro aspecto importante é que o mercado muda e 
a vida muda, é preciso se adaptar as necessidades atuais. 


Penso que um ótimo exemplo do que gostaria que o 
desenvolvimento de jogos fosse é a Riot, pois ela, ao meu ver, já 
superou, em muitos aspectos, os métodos ágeis. Ela está em um 
estágio lean de desenvolvimento. Veja mais informações sobre a 
Riot em seu blog de engenharia 


(https://engineering.riotgames.com/), e alguns links interessantes 
sobre desenvolvimento ágil de games (em inglês): 


e Say no to Rage — Video Games: Agile development: 
https://youtu.be/Y 3BBm3k4Y MI 

e Common mistakes in Agile SCRUM game dev — Arch 
Creatives: https://youtu.be/epWidgZ259M 

e WGDS13, Emil Harmsen, Agile Game Development: 
https://youtu.be/OSijytjjFYsE 


Creio que este livro seja focado principalmente em equipes de 
desenvolvimento de jogos dos mais diversos tipos de empresas. 
Pessoas que, de certa forma, já enfrentaram os desafios expostos 
no livro. 


Mas, talvez, o mais importante de tudo, gosto de acreditar que este 
livro é focado em empresas indie e pequenas de desenvolvimento 
de jogos. Evidentemente, empresas de grande porte também podem 
tirar proveito das metodologias apresentadas, porém, empresas 
maiores possuem muito mais dificuldades de adaptação, e 
geralmente precisam de ajuda externa para identificar seus pontos 
fortes e francos, e onde está bom e ruim. 


Creio também que o leitor ocasional, que tenha interesse em 
desenvolvimento de jogos, terá um bom ponto de partida para 
começar a desenvolver seus jogos a partir das estratégias 
apresentadas neste livro. Porém, o mais importante de tudo, creio 
que poderá levar o desenvolvimento para qualquer ambiente de 
trabalho, seja este desenvolvimento de software, ambiente artístico 
ou governamental. 


Espero que o livro possibilite boas horas de entretenimento e muito 
conhecimento. Não há necessidade de saber programar para ler o 
livro, e todas as etapas que envolvem programação são focadas no 
ponto de vista dos testes. Além do mais, artistas e designers podem 
aproveitar muito para desenvolver suas técnicas de 
desenvolvimento em equipes de games. 


Por último, mas náo menos importante, analistas de negócio e 
gerentes de projeto, talvez as pessoas com mais interesse em 
garantir que as metodologias apresentadas funcionem, e as 
pessoas responsáveis por forçar as pessoas para fora de suas 
zonas de conforto sejam o principal público-alvo do livro. 


Muitos dos links do livro estão em inglês, pois infelizmente não 
há materiais com a qualidade pretendida em português para 
alguns dos links. 


Quando o texto do livro está no plural, refere-se ao pensamento 
da equipe que desenvolveu o jogo. Já no singular, refere-se 
somente a opinião da autora. 


Você pode notar, talvez com um certo estranhamento, que ao 
longo do livro optamos por usar o feminino quando há menção 
de um grupo genérico de pessoas. É uma forma de exercitar a 
conscientização da inclusão de mulheres em tais atividades, 
dando representatividade às desenvolvedoras e jogadoras de 
games, que ainda sofrem bastante discriminação neste 
mercado. 





Prefácio 


Você já percebeu a felicidade das crianças enquanto jogam? 
Amarelinha, esconde-esconde, adoleta, pique-bandeira, Minecraft, 
Halo etc. 


Pois é. Crianças se divertem jogando, mas logo passam de fase: 
crianças, adolescentes, jovens adultos, adultos, adultos mais velhos, 
adultos adolescentes e, por fim, adultos crianças. Porém, existem 
muitas pessoas que não param de jogar (e se divertir) a vida toda! E 
ainda tem aquela turma que trabalha criando jogos. Não fique com 
inveja, essa é a indústria de desenvolvimento de jogos. 


Mas você já sabe disso. Você está com este magnífico livro em suas 
mãos, porque admira software e jogos. E quer continuar jogando, se 
divertindo, colaborando, criando e fazendo os jogos evoluírem. 


Pois bem, a Julia é como você. Ela também gosta e trabalha com 
desenvolvimento de jogos, mas queria mais. Ela queria melhorar a 
vida de quem faz esses jogos. Para isso, ela buscou aprimorar a 
eficácia e a eficiência na criação deles. Julia explorou e combinou 
práticas e técnicas (Lean, Agile, Design Thinking, Lean UX, Lean 
StartUp, entre outras) e alcançou excelentes resultados. 


As pessoas mais próximas tiveram a oportunidade de aprender com 
ela e diziam: “Nossa, mas essa forma de trabalhar é muito show!”. 
Todavia, muitos outros — aqueles que ouviam os relatos de como a 
Julia estava arrebentando, mas não tinham a oportunidade de 
trabalhar diretamente com ela — pediam a ela referências sobre 
essa nova forma de criar jogos. 


Julia atendeu ao pedido e escreveu de forma simples e efetiva como 
ela guia o desenvolvimento de jogos, por exemplo: comece com um 
workshop colaborativo para decidir o direcionamento do jogo, faça 
entregas frequentes do MVG (Minimum Viable Game), desenvolva 
baseado em testes, e integre o código continuamente. 


Neste excelente livro, Julia compartilha todas as etapas da criacáo 
do jogo Super Jujuba Sisters, em plataforma 2D, desde a sua 
concepção às entregas incrementais do MVG. 


Aproveite e se divirta aprendendo. Boa leitura! 


Paulo Caroli 


CAPÍTULO 1 
Introducáo 


Este livro foi pensado de forma a apresentar uma nova maneira de 


desenvolver jogos para equipes com pouca, ou nenhuma, 
experiéncia em metodologias ágeis e/ou lean. 


Lean, ou lean production, pode ser traduzido do inglés para 


enxuto, que deriva do sistema de producáo Toyotista. Este tinha 
como objetivo principal reduzir o desperdício. 





É sempre bom lembrar de que, caso vocé já tenha alguma 
experiéncia, agora é a hora de colocá-la de lado, esquecer tudo o 
que sabe e, com o cérebro limpo, aprender algo novo e sem vícios. 
Nosso objetivo com o Lean Game Development é proporcionar um 
modelo de produção de jogos que evite desperdícios e reduza bugs, 
com reviews constantes e uma sequência de passos que elimina o 
necessário na hora errada. Quando desenvolvemos essa 
metodologia, pensamos em empresas de jogos de pequeno porte, 
mas acreditamos que ela possa ser levada a grandes empresas. 


Por que Lean Game Development e não Agile Game 
Development? 


Lean Game Development poderia ser traduzido para 


Desenvolvimento de Jogos de Maneira Enxuta. 





Consideramos que Lean é algo além do Ágil e, mais importante que 
isso, muitas empresas de jogos tiveram insucessos tentando utilizar 
metodologias ágeis. Temos casos de empresas que confundem 
metodologias ágeis com Scrum, considerando Scrum a única 
ferramenta ágil disponível. 


O mesmo acontece com programacáo extrema (XP — eXtreme 
Programming). Essa confusáo pode ter resultados desastrosos! 
É muito comum empresas adotarem o Scrum, mas náo adotarem os 
princípios básicos do Ágil, gerando um aumento de carga sobre as 
equipes. 


O Lean Game Development foi pensado de forma a atender todas 
as necessidades da indústria de jogos. Assim, há aspectos a serem 
considerados, como a produção de jogos nunca ser 100% 
eficiente, já que não temos como prever todos os possíveis 
problemas. Se estabelecermos prazos fixos e datas limites, o melhor 
que podemos esperar é chegar perto delas, pois problemas não 
planejados continuarão aparecendo, mesmo depois de terminado o 
prazo. É preciso ser orgânico a mudanças, tendo a capacidade 
de se adaptar ao ambiente. 


O Lean Game Development oferece uma alternativa metodológica 
para o desenvolvimento de jogos que pode nos auxiliar a eliminar 
desperdícios, obter resultados no menor tempo possível, fortalecer 
e empoderar o trabalho da equipe e nos permitir uma visão 
melhor do conjunto da obra. Como melhorar a visualização? 
Existe um instrumento para ajudar nesse sentido, o Kanban, que 
literalmente significa cartões de visualização — ferramenta clássica 
nas equipes de desenvolvimento lean. 


Dito isso, é importante salientar que, de forma alguma, o Lean, o 
Scrum, o XP ou o Kanban são excludentes. Eles podem ser 
utilizados em conjunto, permitindo que as melhores características 
de cada um sejam usadas. 


Como o Lean e o Ágil se relacionam no mundo dos jogos? 


O Lean Game Development é, além de tudo, fortemente inspirado 
no Ágil, e pode se aproveitar de todas suas ferramentas para o 
desenvolvimento de software. Portanto, conseguir interpretar o 
manifesto ágil de forma a representar a visão dos jogos pode ser 


uma dificuldade. Para tanto, sugerimos a seguinte visáo do 
manifesto para jogos: 


e Indivíduos e interações mais que processos e ferramentas. 

e Jogo funcionando mais que documentação abrangente. 

e Colaboração com o público mais que vendas. 

e Desenvolvimento espontâneo mais que seguir rigidamente 
um plano. 


Jogos e softwares se relacionam de forma muito mais profunda 


O entendimento do Lean Game Development, de modo que se 
compreenda que o jogo digital é também um software e que o 
desenvolvimento de software pode ser visto como um jogo 
cooperativo de invenção e comunicação, é a etapa chave para o 
sucesso do Lean. Jogos não são somente para crianças, apesar de 
elas adorarem jogar. Jogos são usados para descrever desde 
experiências românticas até estratégias militares avançadas, mas 
também podem ser utilizados como formas de enxergar o 
desenvolvimento de software. 





O jogo de tabuleiro Blitzkrieg foi usado por muito tempo para a 
ajudar a treinar oficiais do exército. O jogo se ambienta na 
Segunda Guerra, na qual dois lados se enfrentam: Great Blue e 
Big Red. São 5 países no total e as alianças não são tomadas 
de forma rígida, podendo variar a forma como o jogo é jogado a 
cada vez. 


O jogo possui 3 modalidades: simples, avançada e torneio. Um 
dos seus aspectos mais interessantes é que, na modalidade 
avançada, ele possui diversas unidades de combate diferentes, 
como infantaria, artilharia, blindados, assalto, cacas, bombardeio 
etc. Infelizmente, costuma ser um jogo difícil de encontrar, talvez 
por ser bastante antigo. A figura seguinte mostra o tabuleiro do 
jogo (gigantesco) com a disposição de uma série de peças 
divididas por cores. 





Figura 1.1: Tabuleiro do jogo Blitzkreig da Avalon Hill. Fonte: boardgamegeek.com 


A 


Quando alguém propõe jogar um jogo, centenas de alternativas 
passam pela nossa cabeça: jogo da velha, damas, xadrez, poker, 
21, esconde-esconde, tênis de mesa, infinitas possibilidades. Mas 
em geral, eles podem ser organizados em algumas categorias que 
auxiliam a percepção de como se joga e quais os objetivos: 


e Soma-zero: jogos que dois lados jogam em oposição e, se um 
ganhar, o outro perde (como damas e jogo da velha). 

e Não soma-zero: jogos com múltiplos vencedores e múltiplos 
perdedores. Exemplos são poker e esconde-esconde. 

e Posicional: quando o estado total do jogo pode ser 
determinado olhando o quadro/tabuleiro, como xadrez e jogo da 
velha. 

e Competitivo: todos os jogos anteriores são competitivos, na 
qual há uma noção clara de ganhar ou perder. 

e Cooperativo: as pessoas jogam junto para ganhar, ou até 
quando julgarem necessário. 

e Finito: jogos que têm como intenção chegar a um fim. 

e Infinito: a intenção primária é se manter jogando. 
Organizações, países e corporações fazem isso. Seu objetivo é 
permanecer no jogo. 


A maior parte dos jogos pode pertencer a diferentes categorias. 


Que tipo de jogo é o desenvolvimento de software? 


Muitas pessoas veem o desenvolvimento de software como um jogo 
posicional, como uma espécie de ciclo de pequenas vitórias, com 
um objetivo bem claro. Mas um software é muito mais do que 
posições em um quadro, muito mais que um jogo no qual sua 
equipe tem de vencer. 


O desenvolvimento de um software é um jogo cooperativo, no 
qual todas as pecas devem se ajudar para atingir cada um dos 
objetivos. Pense em um jogo de sobrevivéncia, em que cada 
integrante da equipe possui uma habilidade única e específica, útil 
para a sobrevivéncia do grupo. O processo de desenvolvimento de 
um software é muito semelhante ao conceito de um jogo 
cooperativo. Náo deve haver um líder, mas um grupo de pessoas 
que se unem para tomar as melhores decisões e dividir tarefas da 
melhor forma possível com o objetivo de sobreviver (vencer). 


Onde erramos? 


Infelizmente, com o passar do tempo, as pessoas desenvolveram a 
concepção de que metodologias mais rígidas e pesadas, com mais 
controle e maior uso de artefatos seriam mais "seguras" para o 
desenvolvimento do projeto. No entanto, sabemos que ninguém 
gosta de jogar jogos com centenas de regras que precisam ser 
lembradas a todo instante para que a jogadora se mantenha em 
condições de jogar corretamente/bem. 


Os jogos mais divertidos e com melhores resultados são aqueles 
que podem ser jogados de forma mais relaxada, de modo que, se 
uma regra for quebrada, não haverá grandes consequências para o 
seu resultado. Além disso, jogos que permitem criatividade e 
imaginação tendem a gerar muito mais cooperação. Basta observar 
crianças jogando jogos de tabuleiro. 


Considerando isso, por que não pensar o mesmo do 
desenvolvimento de software? Um exemplo do efeito negativo da 
rigidez e do peso seria o seguinte: conceba o jogo Banco Imobiliário 
(Monopoly). Agora imagine que, além das jogadoras, teremos uma 
pessoa unicamente responsável por administrar o banco, uma 
responsável por administrar os imóveis, outra para administrar o 
banco de imóveis, uma para administrar sua vida (cartas da sorte ou 
revés), uma como polícia para administrar as prisões e fluxo dos 
personagens, outra para jogar os dados etc. 


O modelo recém-apresentado é o modelo de desenvolvimento de 
software utilizado na maior parte das empresas: altamente 
hierarquizado, com diversos controles sobre os indivíduos, regras 
rígidas, dificuldade de jogar, com o objetivo de explorar os outros. 
Como esse modelo pode ser superior a um modelo relaxado, 
divertido, criativo e cooperativo? 


Na verdade, é o contrário que é correto. O manifesto, o 
framework, a metodologia não devem ser aplicados de forma 
rígida e imutável, pois, afinal, o jogo deve permitir a diversão. 


Provavelmente, esta presunção de que metodologias mais pesadas 
são mais seguras vem da suposição de que as gerentes de projetos 
não conseguem olhar para o código e avaliar o grau de 
desenvolvimento, o estado e a situação do projeto. Adicionar peso 
e rigidez ao modelo não fará com que o temor e a insegurança 
quanto ao andamento do projeto contribuam para que ele se 
torne melhor. Na verdade, a consequência será fazer com que a 
equipe atrase seu trabalho e perca o prazo de entrega. 


Para obter resultados satisfatórios, é preciso ter sempre em mente 
que o desenvolvimento de um software é um jogo em equipe, 
no qual o gerente de projeto não está acima de ninguém. É 
preciso lembrar de que existem formas de documentar a medida em 
que se escreve o código, e que há maneiras de visualizar o 
desenvolvimento do software sem aumentar a pressão sobre a 
equipe. 


Alguns preconceitos da indústria de jogos em relação à metodologia 
ágil são: 


e A automação de testes em jogos é muito mais complexa do que 
em outras indústrias de software. 

e O visual não pode ser testado de forma automática. 

e A contratação de crianças para testar o jogo é muito mais 
barata. 


e O modelo atual de negócios no setor é louco e baseado em 
jogos prontos. 

e "Não gosto de Scrum”, como se o Scrum fosse a resposta 
absoluta a metodologias ágeis. 

e As sequências de jogos não são iterações. 

e Arte não pode ser iterada e jogos são arte. 

e Jogos são desenvolvidos de modo que os usuários joguem por 
mais tempo e não que eles poupem tempo. 

e Jogos não são testáveis. 

e Do ponto de vista da produção, a entrega contínua não é 
atraente para jogos. 


Assim, é importante entender o básico de Lean para se poder dar os 
primeiros passos; lembrar-se de que o desenvolvimento de software 
deve ser um jogo cooperativo e divertido, na qual todas as peças 
são importantes e um jogo que sempre gere mais conhecimento. 
Idealmente, deve ser gerenciado de forma orgânica e pouco 
hierarquizada com o objetivo de evitar desperdícios (de potencial 
humano, de tempo, de documentação excessiva, de conflitos, de 
estresse etc.). 


Desta forma, o livro abordará diversos aspectos do desenvolvimento 
lean, como o básico, Inceptions e MVPs, de forma mais profunda e 
aplicada a jogos. Também será visto desenvolvimento guiado a 
testes e tudo o que pode ser incluído no desenvolvimento, um pouco 
de como fazer integração contínua em jogos, como gerar hipóteses. 
Por último, será abordada uma breve diferenciação entre design e 
build, um pouco mais sobre testes, medições e análises, geração de 
ideias e muito sobre jogos. 


CAPÍTULO 2 
Primeiros passos no Lean 


Antes de explicar melhor o Lean, é importante falar os seus 7 
princípios-chaves, pois assim a leitora poderá refletir sobre eles à 
medida que lê o livro: 


1. Eliminar o desperdício: produzir além do necessário de forma 
desordenada, fazer uso desnecessário do inventário e dos 
requerimentos, dar excessiva importância aos defeitos, 
processar informações desnecessárias, tempo de espera 
elevado. Para esses objetivos serem alcançados, evite códigos 
e funcionalidades desnecessários. Outra questão importante é 
não começar mais atividades do que podem ser completadas. 


Do ponto de vista de negócio, é preciso elaborar os 
requerimentos para que sejam de fácil compreensão, ou evitar 
alterá-los constantemente. Evite principalmente a burocracia. 
Um problema comum é a comunicação ineficiente, que pode 
provocar falta de compreensão em relação ao trabalho que 
deve ser feito. Do ponto de vista da desenvolvedora, é 
importante cuidar para não deixar trabalho incompleto, ou 
defeitos e problemas de qualidade em código de build. Mas 
talvez o mais importante seja evitar a mudança desnecessária 
de tarefas. 


2. Construa com qualidade: problemas de qualidade resultam 
em desperdício, e existe desperdício em ter de testar algo mais 
de uma vez. Por exemplo, para evitar problemas de qualidade, 
pair programming e Test Driven Development são ferramentas 
fundamentais, e ambas serão descritas com profundidade em 
capítulos futuros. 


3. Gere conhecimento: gere conhecimento de forma que toda a 
equipe consiga acompanhar o desenvolvimento do software e 


adquira a capacidade técnica para lidar com ele. Uma maneira 
comum de gerar conhecimento é através de pair programming. 
Porém, wikis, dev huddles e docs podem ser ferramentas para 
compartilhar conhecimento também. 


4. Adie comprometimento: soluções complexas não devem ser 
tratadas precipitadamente, e decisões irreversíveis não devem 
ser tomadas antes da hora. 


5. Entregue rápido: é comum as pessoas passarem muito tempo 
pensando em requerimentos que possam ou não aparecer. 
Também ocorre com frequência que elas fiquem bloqueadas ou 
pensando em soluções de engenharia excessiva. A solução 
desse problema se resume a: reunir as pessoas certas, 
manter as coisas simples, trabalhar como uma equipe, e 
tudo que já foi dito anteriormente. 


6. Respeite as pessoas: local de trabalho deve ser agradável, 
mas não esqueça nunca da cortesia entre as pessoas. Não 
importa qual seja a sua posição na empresa, você deve sempre 
buscar a equidade entre as partes. 


7. Otimize o todo: esse princípio parece algo bem simples e 
intuitivo, mas geralmente não é levado em conta. É importante 
identificar falhas, propor soluções para elas e buscar feedbacks. 
Um todo não é simplesmente formado por suas partes, mas 
pela interação das pessoas e suas tarefas das partes. 


No uso das metodologias descritas a seguir, é sempre importante 
manter os princípios-chaves do lean em mente. 


2.1 Lean Inception 


Uma etapa muito interessante do desenvolvimento de softwares por 
meio da metodologia lean é a Lean Inception. Podemos descrevê-la 


resumidamente como um workshop, tipicamente de uma semana, 
com muitas atividades de alinhamento e definição de objetivos. A 
evolução do produto acaba sendo representada por uma sequência 
de MVPs e suas features. 


O objetivo principal é definir o escopo do que está sendo criado, 
para que no final a equipe tenha uma visão clara do caminho a ser 
seguido, em geral, através do MVP Canvas. O MVP Canvas será 
explicado posteriormente, mas uma breve explicação vai bem a 
calhar. 


O MVP Canvas une elementos do Design Thinking, do Lean 
Startup e diretivas de negócios. É um template de validação de 
novas ideias e de clarificação de ideias já existentes. É dividido 
em 7 elementos: 


e Visão do MVP: qual a visão de produto que este MVP deve 
entregar? 
Métricas para a validação das hipóteses: como nós 
medimos os resultados deste MVP? E do ponto de vista de 
negócio? 
Declaração de resultado: quais aprendizados queremos 
obter com este MVP? 
Funcionalidades: o que pretendemos construir com este 
MVP? Que ações podem ser tomadas para simplificar o 
MVP? 
Personas e plataformas: para quem é este MVP? 
Jornadas: quais jornadas de usuário serão melhoradas 
neste MVP? 
Custo e agenda: qual será o custo e a agenda para este 
MVP? 


Veja mais em http://www.caroli.org/the-mvp-canvas/. 





Como se aplica no caso de jogos? 


Uma das principais funções da Lean Inception pode ser a ideação 
de features do jogo, o seu design básico (game design) e as 
ferramentas a serem utilizadas. Em suma, há toda uma série de 
aplicações possíveis. É importante envolver toda a equipe, pois 
isso aumenta a motivação e favorece a construção do 
empoderamento do grupo. 


2.2 Lean PMO 


O Lean PMO organiza e mantém o controle das demandas e dos 
MVPs. Permite um olhar considerando o conjunto da obra, sem se 
perder em detalhes técnicos do Ágil, como ocorre no caso do XP, do 
Scrum e do Kanban. 


Sua principal função é garantir a entrega contínua. É estar 
atento ao todo e não aos detalhes, e fazer acompanhamento 
periódico do desenvolvimento do produto. PMO vem do conceito de 
Project Management Office, mas neste caso se aplica à equipe que 
gerencia o desenvolvimento do jogo. 


PMO (Project Management Office) é um grupo de pessoas (ou 
um indivíduo) que são responsáveis por manter uma visão 
integrada do planejamento estratégico ao longo de todo o 


desenvolvimento do produto, inclusive garantindo prazos e 
custos. São responsáveis por reunir todo o portfólio da empresa 
para conduzir, planejar e organizar as atividades dos projetos da 
melhor forma possível. 





Como o Lean PMO se aplica no caso dos jogos? 


Falar de entrega contínua quando o jogo ainda não está no mercado 
parece um tiro no pé, mas a entrega contínua não precisa ser 
necessariamente para uma cliente usuária, jogadora. A ideia por 


trás disso é o gerenciamento das etapas de tal forma que o 
produto continue evoluindo. 


2.3 Lean DevOps 


A funcáo do DevOps é conectar as práticas de DevOps á 
perspectiva do Lean MVP, que será descrito no capítulo seguinte. 
Náo deixa de ser uma descricáo das práticas que a equipe utiliza na 
criacáo do produto. 


Não precisa ser executado por uma única pessoa; pode ser usado 
por um conjunto de pessoas, pessoas diferentes em momentos 
diferentes, em diferentes atividades práticas. Inclui o trabalho com 
features e com as histórias de usuários. 


Como se aplica no caso de jogos? 


Pode-se, por exemplo, indicar pessoas que fiquem responsáveis por 
organizar e aplicar as técnicas, as metodologias e as ferramentas 
que a equipe definiu, bem como por orientar e auxiliar na sua 
implementação. 


2.4 Kanban 


O Kanban é baseado no modelo just-in-time da Toyota. O método 
consiste em visualizar o fluxo de trabalho e, a partir disso, atuar 
no processo para não sobrecarregar os membros da equipe. O 
processo é exposto a esses membros por meio da abordagem de 
gestão visual, desde a etapa inicial até a entrega final. 


Podem ser usados quadros físicos (quadro branco ou cartazes) ou 
quadros virtuais, como o Trello. Nem todos os Kanbans precisam 


ser divididos por colunas e fileiras. Existem implementações 
bastante criativas, basta procurar aquela que mais se aproxima das 
necessidades da equipe. 


O Kanban é composto de diversos "cartões", sendo que cada um 
significa uma ação que deve ser realizada, e seu grau de conclusão 
está sinalizado em um painel, geralmente chamado de Heijuka 
Board. Esse sistema possui algumas vantagens, tais como a 
facilidade de identificar desperdícios e ciclos mais rápidos, que 
aumentam a produtividade. 


Algumas maneiras de indicar o estado do cartão incluem 
sinalizações em cores que permitem identificar atrasos, permitindo 
que eles sejam atendidos primeiro. Cartões diferentes na mesma 
zona geralmente indicam falha de fluxos e devem ser atendidos. 


Ao meu ver, isso ajuda a eliminar dailys longas, a necessidade de 
um Scrum master e outros desperdícios. Muitas vezes, tarefas 
trabalhosas demais podem significar que elas podem ser divididas 
em tarefas menores, com ganho de eficiência. 


O conceito de WIP (work-in-progess) é usado de forma a limitar as 
atividades a serem “puxadas” no Kanban. Do ponto de vista do 
Kanban, a próxima atividade somente é puxada quando o WIP tiver 
capacidade de trabalho. As restrições de WIP identificam gargalos e 
áreas possivelmente problemáticas no processo, o que ajuda na 
tomada de decisões da equipe (mais em http://www.caroli.org/sobre- 
o-kanban/). 


2.5 Como podemos aproveitar o Scrum? 


Todos já devem ter uma ideia clara do que é o Scrum, mas convém 
repetir. O Scrum é um framework ágil para a conclusão e gestão de 
projetos complexos. Altamente recomendado para projetos que 
possuem requisitos que mudam rapidamente. 


Sua progressão ocorre através de iterações chamadas de Sprints, 
que geralmente duram de uma a quatro semanas. O modelo sugere 
que cada sprint comece com uma reunião de planejamento e 
termine com uma de revisão do trabalho realizado: ciclos curtos e 
cadenciados, com reuniões de alinhamento, acompanhamento da 
evolução do trabalho e eficiência da equipe 
(http://www.caroli.org/sobre-o-scrum/). 


Outras etapas, como retrospectiva e grooming, devem ser 
consideradas palavras-chaves. Geralmente, corresponde a 
cerimónias da equipe com o objetivo de revisar os passos feitos e 
de planejar os próximos. 


Nesse framework, costumam ocorrer com frequéncia reunides 
denominadas dailys, que permitem a equipe verificar o andamento 
das tarefas. Resumidamente: todos os membros da equipe ficam de 
pé e respondem a trés perguntas: “O que fiz ontem?", "O que vou 
fazer hoje?", "O que está me bloqueando?". As respostas a 
essas perguntas servem de material para a reflexáo, reorientacáo e 
tomada de decisões por parte da equipe. 


A utilização do Scrum fomenta o fortalecimento de uma equipe 
multifuncional e auto-organizada. A eficiéncia da equipe depende da 
sua capacidade de trabalhar em conjunto. Isso requer que ela não 
tenha um líder, pois ela deve tomar decisões com a participação de 
todos. 


PALAVRAS-CHAVES PARA MEMORIZAR 


e Scrum Master: pessoa familiarizada com o framework, que 
tem como objetivo facilitar o time no processo scrum. Pode 
ser alguém da equipe de desenvolvimento. 


Product Owner: representante da empresa, das clientes ou 
das usuárias que orienta a equipe sobre a visáo do 
produto**. Deve liderar o esforco de desenvolvimento 
através de esclarecimentos e estabelecimento de 
prioridades. 





2.6 Integracáo contínua 


É uma prática de desenvolvimento de software na qual os membros 
do time integram frequentemente o seu código. Cada integracáo é 
verificada por meio de uma compilacáo e testes automatizados para 
detectar de forma rápida erros de integracáo. 


A integração supõe um alto nível de testes automatizados. Mais 
adiante, veremos mais sobre integracáo contínua, mas ferramentas 
comuns para jogos sáo a Unity Cloud Build e o Jenkins. Teremos um 
capítulo inteiro sobre isso adiante. 


2.7 Partindo do Build Measure Learn até o Lean 
Game 


A seguir, apresentamos sumariamente algumas etapas do processo 
de desenvolvimento de software lean. Algumas adaptações podem 
ser feitas na figura seguinte para descrever o desenvolvimento de 
jogos, mas a ideia central é gerar ideias, construir, codar, medir, 


obter dados, aprender com os dados e gerar novas ideias, tudo 
de forma que ocorra em /oop. 





Figura 2.1: Diagrama Build Measure Learn. Fonte: www.caroli.org/what-to-build/ 


Como solucáo para o diagrama da figura anterior no contexto 
de desenvolvimento de jogos, obtemos o diagrama da figura a 
seguir. 
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Figura 2.2: Diagrama de Lean Game Development. Inspirado em www.lithespeed.com/lean- 
ux-dont-part-1-3-2/ 


Explicando rapidamente as etapas anteriormente mostradas, 
obtemos: 


e Inception: conceito definido na seção de Lean Inception 
Engloba uma série de etapas, descritas a seguir. 

o Definição de objetivos (define goal): momento no qual a 
equipe se junta para construir os ideais em que a Inception 
se baseará. 

o Pesquisa (Research): um momento no qual o time pode se 
informar sobre as possibilidades que os objetivos 
permitem. 

o Insights: momentos de inspiração de ideias com o objetivo 
de pensar "fora da caixinha". 

o Brainstorming: este é o momento para expor sua 
criatividade e não ter medo de suas ideias. Quanto mais 


absurdas, melhor. 

o Hipóteses (Hypothesis): momento que permite tornar 
todas as ideias geradas em objetivos mensuráveis. 

e Desenho do jogo (Design): na nossa opinião, um dos 
momentos mais interessantes. É o momento em que o jogo 
ganha forma. 

o Revisar as hipóteses (Revise Hypothesis): com o atual 
desenho do jogo, pode se fazer a primeira medição, que 
consiste em determinar se as hipóteses geradas são 
adequadas ao contexto. 

e Construção do jogo (Build): momento no qual se define o que 
é possível fazer e como fazer. 

o Codar (Code): momento de desenvolvimento de artes, 
animações, códigos, modelos etc. 

o Testar (Test): momento para se obter os primeiros 
feedbacks do que se está fazendo, mesmo que de forma 
automatizada. 

e Medir (Measure): com o build pronto, devemos medir o impacto 
do jogo. Existem diversas maneiras, mas feedbacks de 
comunidades são uma ótima maneira de se começar. 

e Analisar (Analyze): momento em que se desenvolve uma 
compreensão de tudo que foi medido. 

e Iterar: no Lean, é importante sempre iterar para se poder gerar 
novas ideias, conceitos, features, aprendizados. Iterar consiste 
em começar de novo. 


2.8 Um pouco mais a fundo no conceito de 
Inception 


Inception é uma atividade muito útil para dar o "pontapé inicial" ao 
projeto e definir as histórias de usuários. Nessa etapa, as perguntas 
importantes são: 


e Quais são os objetivos deste projeto? 

e Quem vai usar esse sistema? 

e Quais os papéis que cada membro da equipe desempenhará no 
desenvolvimento do jogo? 


Uma vez formulados alguns objetivos, a equipe pode passar a 
desenvolver as jornadas de personas (veremos o conceito de 
personas no capítulo seguinte) utilizando a sequéncia: Como X, eu 
quero Y, portanto, Z, Então, o que X quer do sistema para atingir z? . 
A partir dessas perguntas e respostas, sáo criadas histórias nas 
quais o software deve se basear. 


Como se aplica a jogos? 


Como em outros casos, o modelo apresentado náo é perfeito para 
jogos, pois sempre faltam alguns ideais. Como podemos adaptar e 
melhorar esse modelo? Sugerimos as seguintes perguntas: 


e Qual a narrativa do jogo? 

e Qual é a característica central do jogo? 
e O que queremos obter com esse jogo? 
e Que tipo de usuário estamos visando? 
e Como eles poderão jogar o novo jogo? 


Esclarecidas essas questões, poderemos determinar as jornadas 
das jogadoras: 


e Como X, eu quero poder fazer Y, portanto, quero Z. 
e Entáo, o que X quer fazer no jogo para obter Z? 


2.9 Desenvolvimento Guiado a Testes (TDD) 


O Test-Driven Development (TDD) evita problemas por escrever 
testes antes de desenvolver códigos. Se as desenvolvedoras sabem 
como o jogo é testado, elas possuem maior probabilidade de pensar 


em todos cenários de teste antes de codificar, o que pode melhorar 
muito o design de código. Os passos mais comuns do TDD sáo: 


Escrever o teste. 

Rodar o teste e vé-lo falhar. 
Escrever o código. 

Rodar o teste e ver o teste passar. 
Refatorar. 

Iterar. 


Mais adiante, teremos um capítulo focado somente em TDD, 
especialmente no espectro de jogos. 


Lean e jogos 


Com todo esse conhecimento básico adquirido até agora, é possível 
entender superficialmente o que é o Lean e algumas aplicações 
desses tópicos a jogos. Para tanto, podemos pensar agora qual é o 
primeiro passo para entender o desenvolvimento de jogo lean, uma 
Inception, por exemplo. Além disso, é um bom momento para se 
refletir sobre o que as figuras apresentadas anteriormente neste 
capítulo podem nos ensinar e que passos devemos tomar. 


CAPÍTULO 3 
Uma Inception na prática! 


Já falamos o que é uma Inception no capítulo anterior, mas nosso 
objetivo agora é validar sua importáncia. Muitas vezes, antes de 
começar um projeto, os membros da equipe não se conhecem. 
Assim, uma de suas funções é aumentar o entrosamento do time. 


Existem várias técnicas chamadas de ice breakers para auxiliar 
nisso. Com isso resolvido, passamos para tópicos como definição 
de objetivo, estratégias e escopo do jogo, mapeamento e 
priorização de funcionalidades. 


A forma como pensamos a Inception é inspirada no que Paulo Caroli 
descreve em seu blog: 


COMO MODELAR UMA INCEPTION? 
Geralmente, seguimos um modelo bem simples: 


e A Inception dura de 1 a 5 dias, dependendo da 
complexidade do jogo e da necessidade. 

e Contamos com a presença de toda a equipe de 
desenvolvimento, publishers, analistas de negócio e demais 
interessados no sucesso do jogo. 

e Um war room reservado para a Inception por quanto tempo 


for necessário (de preferéncia, que a "bagunca" se 
mantenha). 

e Muitos post-its coloridos para nos permitir muito 
brainstorming. 


Mais informações sobre Inceptions podem ser encontradas em: 


e http://www.caroli.org/back-to-the-basics-what-made-this- 
agile-inception-especial/ 
e http://www.caroli.org/user-stories-and-business-hypothesis/ 





A figura a seguir mostra uma série de regras para tornar um 
brainstorming mais produtivo. Ela foi desenvolvida por Gabriel Albo, 
da Thoughtworks, e foi inspirada na ideia proposta em 7 Tips on 
Better Brainstorming (OPENIDEO, 2011). 


Regras E 


BRAINSTORMING 


Quantidade importa. 
Procure criar o máximo de ideias 
pes 


Encoraje ideias 
malucas. 


Mantenha o foco. 
Fique no assunto proposto. 





Figura 3.1: Regras para brainstorming 


3.1 Como e por que fizemos uma Inception? 


Nosso problema era como desenvolver um jogo de computador, 
nossa paixáo, de forma a tirar maior proveito das técnicas que 
utilizamos no dia a dia. Criar um modelo de desenvolvimento de 
jogos que permitisse outras empresas de jogos desenvolver de 
forma mais proveitosa e com maior qualidade. Portanto, 
precisávamos comecar de algum lugar, a Inception! Juntamos 
pessoas interessadas e comecamos a pensar. 


3.2 Como foi a Inception? 


Nossa Inception contou com a presenca de algumas pessoas de 
fora da equipe de desenvolvimento do jogo, já que ela era pequena. 
Durou aproximadamente um dia, mas suas etapas somente foram 
encerradas ao longo da semana com o time de desenvolvimento. 


O que apresentamos a seguir é focado na etapa de ideacáo da 
Inception. Ela consiste em uma etapa de definicáo de objetivos, 
insights, brainstorming e geracáo de hipóteses. 


DEFINIÇÃO DE OBJETIVOS 


Um conjunto de metas que a equipe define como prioritárias 
para alcançar o que se espera do jogo. 


Insights 


Uma compreensão das necessidades do jogo, respeitando seus 
objetivos de forma a gerar ideias claras de como alcançar esses 
objetivos desejados, uma epifania de narrativa e de arte no 
contexto de games. 


Insights se diferem de brainstorming de forma que os insights 
representam uma compreensão de formas de alcançar os 
objetivos, e muitas vezes servem como base do brainstorming, 
que tem como objetivo gerar ideias sobre o que foi estabelecido 
nos insights e nos objetivos. 





Apresentamos as ideias que foram mais relevantes e as mais 
divertidas, ao desenvolvimento do jogo. 


Qual a narrativa do jogo? 


e Jogo do Mário. 

e Jujuba enfrenta inimigos de uma gangue. 

e Marcibal e a gangue dos Xandra sequestram mulheres para 
rituais satânicos. 

e Mundo pós-apocalíptico. 

e Coisas escondidas e explosivas. 

e Quem não gosta de gatinhos e bombas. 

e Armas de Choque. 

e Kamehamenhaaaaa! 


Qual a característica central do jogo? 


e Plataforma 2D. 


e Caminhar, pular, cair. 
e Morrer e renascer, ou seja, vidas! 
e Matar inimigos. 


O que queremos obter com o jogo? 


e Provar que Lean Game Development pode ser aplicado para 
desenvolvimento de jogos. 

e Provar que pequenos projetos podem tirar muito proveito das 
metodologias ágeis e lean. 

e Muita diversão e aprendizado. 


Em que tipo de usuária estamos focando? 


e Pessoas que querem se divertir com um jogo envolvente. 

e Foco em jogos rápidos. 

e Usuárias com foco em jogos com grau de dificuldade 
crescente. 


Como as usuárias poderáo jogar? 


e Movimentos restritos ao teclado, como direcional, espaço e 
asdw. 

e Controle de videogame? 

e Sem recursos externos 


3.3 Priorização de ideias 


Com todas essas ideias geradas, é necessário fazer uma 
priorização. A maneira como fizemos é a seguinte: 


e Cada pessoa ordena sua sequência favorita (no caso da 
narrativa do jogo, nos restringimos a ordenar as 3 favoritas). 
Quando todas terminarem, a ordem é exposta. 

e Utilizando a sequência gerada pela ordem de preferência 
(sistema de voto preferencial), criamos um quadro com as 


sequéncias em cada uma das perguntas anteriores. 

e À partir das sequências criadas anteriormente, geramos itens 
de ação, que são novamente votados e ordenados, mas desta 
vez todos eles pertencem ao mesmo grupo. 

e Os itens são usados em um debate para definir quais são 
prioritários e quais são mais fáceis de se resolver primeiro. 

e Com esses itens de ação, podemos gerar os MVPs descritos no 
próximo capítulo, personas e jornadas de usuário. 


3.4 Desenvolvimento das personas 


Personas são uma forma que a equipe pode, durante o 
desenvolvimento do jogo e a Inception, idealizar perfis de suas 
principais usuárias. Envolve atributos como interesses pessoas, 
idade, emprego, hobbies etc. 


Criação de personas 


1. Solicite ao time que se divida em pares ou trios, e entregue o 
seguinte template (figura a seguir) de personas para cada 
grupo. 

2. Solicite a cada grupo que crie uma persona, utilizando o 
template como referência; 

3. Solicite às participantes que apresentem suas personas a todo 
o time; 

4. Solicite ao time que mude os grupos e repita os passos de 1 a 
3. 





Figura 3.2: Template de personas de Natalia Arsand. Fonte: http://www.caroli.org/atividade- 
identificando-personas 


Ao final da atividade, um conjunto de personas deve ter sido criado 
e os diferentes tipos de usuárias do jogo devem estar descritos. As 
stakeholders que conhecem os objetivos do projeto devem participar 
ativamente da atividade, auxiliando a equipe na criacáo das 
personas e sugerindo alterações em suas descrições, conforme 
necessário. Além disso, muitas das ideias geradas na Inception 
podem ser muito bem aproveitadas aqui, demonstrando a 
necessidade da pesquisa prévia sobre o jogo 
(http://www.caroli.org/atividade-identificando-personas/). 


É importante lembrar de que os resultados de definicáo de 
personas náo sáo definitivos, e sim uma construcáo inicial que 
pode e deve ser iterada, repensada e evoluída com cada 


iteração. Vale dar uma lida em 
http://www.caroli.org/diretoaoponto-criar-as-personas-todos- 
junto-ou-trazer-uma-apresentacao-pronta/. 





Jornadas de personas 


O texto das personas foi copiado exatamente como o 


desenvolvido durante a Inception. 





e Como Carlita, quero poder fazer a princesa salvar o dia, 
portanto, quero que a personagem principal seja feminina. 

e Como Rodrigo, quero poder passar horas jogando, para isso, 
quero que a experiência de jogo seja diferente em cada 
etapa. 

e Como Thais, quero que os inimigos sejam reais e 
personificados, portanto, quero que eles se baseiem em 
situações reais e verossímeis. 

e Como Guilherme, quero que o jogo me lembre dos tempos 
antigos de videogame, por isso, quero uma experiência do tipo 
Mario 2.0. 


O que precisamos? Histórias 


Esta é a etapa em que extraímos os conceitos de arte, as 


features, as mecánicas e a experiência de usuário (UX) das 
personas. 





e Carlita quer que a Jujuba seja uma personagem forte, e assim 
como em Frozen, quer que o enredo gire em torno de irmãs. 


e Como Rodrigo, quero que cada nível apresente novos 
desafios, tais como novos inimigos e habilidades novas. 

e Thais quer que os personagens produzam uma sensação de 
identificacáo e/ou de humanidade. 

e Para Guilherme, é importante pular, caminhar, cair. 


3.5 Próximos passos da Inception 


No final do próximo capítulo, entraremos em detalhes sobre como 
montamos os MVPs, mas há algo que faltou: como as jornadas de 
usuário, personas e hipóteses viram MVPs. Na verdade, elas náo 
viram MVPs, mas sáo extraídas do mesmo lugar e usadas de forma 
a gerarem os conceitos de entrega de valor (MVPs) e os conceitos 
de validacáo de entrega (hipóteses). 


3.6 Como ficou o jogo do ponto de vista da 
Inception? 


Teremos um jogo plataforma 2D em que a personagem Jujuba deve 
sobreviver a uma série de desafios para resgatar sua irmá Xuxuba 
das máos do maléfico Marcibal, membro da gangue dos Xandra. 


Neste capítulo, vimos como funciona uma Inception e que tipo de 
informacáo podemos extrair dela (como narrativas, estética e 
características do jogo, nossos objetivos, nossas usuárias e nossas 
mecánicas). Vimos também como pode ser feita a priorizacáo de 
ideias geradas em uma Inception e o desenvolvimento de personas 
que nos guiaráo através do desenvolvimento. 


Com essas informações, obtivemos as features que o jogo deve 
apresentar e uma ideia de sequência delas. E a partir deste 
momento que surge o conceito de MVPs, e como priorizá-los e 


ordená-los. Mais detalhes sobre MVPs seráo apresentados no 
capítulo a seguir. 


CAPÍTULO 4 
MVPs, realmente precisa? 


Já retratamos bastante a palavra MVP, ou seja, Minimum Viable 
Product (mínimo produto viável) nos capítulos anteriores, mas náo 
explicamos o que MVP realmente é. O MVP é o mínimo conjunto de 
funcionalidades essenciais necessárias para que se tenha um 
mínimo produto funcional que entregue valor para o negócio 
(produto mínimo) e que possa ser utilizado pela usuária final 
(produto viável). Ele funciona de forma incremental, de modo que 
cada novo MVP entregue o próximo conjunto de funcionalidades 
mínimas, o que permite ao produto ter um aumento de valor 
constante. 


O conceito de MVP náo é algo táo simples quando se trata de jogos, 
pois na maior parte dos casos as empresas querem entregar um 
jogo pronto e completo, assim como as clientes querem o jogo mais 
completo possível com uma experiéncia única. Portanto, precisamos 
de um mínimo jogo viável (MVG — Minimum Viable Game), mas é 
preciso lembrar de que um jogo mínimo viável deve, além disso, 
agregar algum valor. 


É preciso perguntar: o que seu jogo possui de diferente? Qual a 
qualidade que o torna único? Todas as features sáo realmente 
necessárias? É preciso desenvolver tudo a partir do zero, ou já 
existem ferramentas para ajudar no desenvolvimento? Essas 
ferramentas satisfazem todas as suas exigéncias? Vocé possui o 
feedback necessário para a sua ideia? Sua equipe é integrada? 


Nesse ponto, nos deparamos com dois conceitos distintos: o MVG, 
que define o ponto em que o jogo é apresentável para o cliente; e o 
protótipo, uma espécie de minimum viable prototype (mínimo 
protótipo viável). Quando desenvolvemos jogos, especialmente 
aqueles com features novas, é preciso ter em mente que o 
desenvolvimento de jogos é feito com protótipos de features e 


mecánicas. Ninguém comeca desenvolvendo um jogo com features 
avançadas, animações para todos objetos e artes perfeitas. 
Geralmente, um protótipo parece algo como a figura a seguir, algo 
semelhante a um jogo de Atari em 3D. 





Figura 4.1: Um exemplo de possível protótipo 3D. Fonte: New York Film Academy 
(https: //www.nyfa.edu/student-resources/getting-the-most-out-of-your-prototype-game/) 


Por que fazer protótipos? 


Protótipos servem para que as etapas do trabalho sejam 
desenvolvidas com cuidado e para que os problemas aparecam 
na hora certa. Náo desejamos um bug bloqueante no jogo, que 
surpreenda a cliente enquanto ela está se divertindo. 


Essas perturbações são comuns em jogos de corrida, por exemplo, 
quando ocorre um pulo maior do que o esperado pelas 


desenvolvedoras e o carro fica preso dentro da montanha. Para 
ajudar a superar essa dificuldade, o MVG possui vários protótipos, 
quantos forem necessários, cada um deles com uma única feature, 
uma única mecánica implementada e/ou entáo uma nova 
arte/animação implementada. 


Não tente implementar milhares de coisas ao mesmo tempo, seu 
bem-estar emocional agradecerá. O MVG é simplesmente um 
conceito genérico que descreve o mínimo conjunto de protótipos 
que devem ser agregados para tornar seu produto viável 
comercialmente; já o protótipo é o mínimo conjunto de features que 
devem ser desenvolvidas para que ocorra entrega de valor. Outra 
diferenca é que o MVG envolve entrega de valor a cliente, enquanto 
o protótipo geralmente entrega valor ao negócio. 


4.1 O papel da PO nos MVGs/protótipos 


Sabemos que o MVG/protótipo precisa de uma Product Owner. 
Quem pode ser a PO da equipe? Quem pode ser a pessoa que se 
encarregará de garantir que o desenvolvimento do jogo está 
seguindo a visáo desejada? É claro que sempre que pensamos em 
POs, associamos a ideia de Scrum. Mas é realmente só isso que 
queremos levar em conta? 


Quando um jogo está sendo desenvolvido, é muito fácil a 
equipe se perder e passar anos desenvolvendo um jogo novo 
cada semestre. Basta lembrar o exemplo do jogo FEZ, que aparece 
no documentário Indie Game: The Movie. O idealizador do jogo, 
designer e desenvolvedor, era também o PO, a pessoa que garantia 
a visão do jogo. Essa duplicidade de funções fez com que o jogo 
levasse muitos anos para ser lançado e, em consequência, essa 
demora teve um impacto negativo no marketing do produto. 


A PO deve ser alguém que entende como as usuárias e o 
mercado váo se comportar. Muitas vezes náo precisa ser alguém 
do quadro interno da empresa, mas alguém que possa fazer 
pequenas consultorias para garantir a integridade e a visáo correta 
do produto; alguém capaz de definir as features mais importantes e, 
de preferéncia, que possa acompanhar o desenvolvimento do 
jogo em todos os estágios. 


Outra funcáo importante da PO pode ser determinar quando os 
MVGs foram atingidos. Por exemplo, um bom conceito de MVG é 
lancar alfas e betas, como ocorreu com o Minecraft. Minecraft é um 
dos jogos indies de maior sucesso dos últimos tempos e seu 
impacto de mercado foi enorme, isso é incontestável (eu mesma já 
passei horas jogando com meu filho). 


Quais seriam, entáo, os produtos mínimos viáveis quando falamos 
em jogos? Nossa sugestão é: 


e Alfa: pode ser um lancamento interno na empresa, para as 
desenvolvedoras e designers testarem e opinarem. Amigos e 
família são boas opções. 

e Demos: quem não gosta de ver uma demo sendo jogada na 
internet? Youtubers são uma ótima chance de tornar seu jogo 
conhecido pelo público, sem esquecer que todo tipo de 
feedback pode ser positivo para seu jogo. 

e Beta: nesse caso, pode-se atingir um público mais geral. 
Aproveite essa etapa para conseguir feedbacks, identificar 
falhas, bugs e features faltantes, e para determinar quais são os 
pontos fortes e fracos de seu jogo. 

e Soft Launch ou Early Launch (pré-lançamento): esses são 
estágios importantes, que permitem uma boa avaliação de 
quanto vale seu produto. Como nessa etapa ele deve estar 
quase totalmente pronto, é uma boa ideia receber o máximo de 
feedbacks e corrigir os erros faltantes. 

e Marketing: também faz parte do jogo e utilizará recursos dele. 
Que tal um site que permita jogar uma pequena feature do 
jogo? 


e Public Launch (lançamento público): nesse caso, é desejável 
que o seu MVG esteja em condições de ser lançado para o 
público em geral. 

e Cross-platform (multiplataforma): melhor opção é lançar o jogo 
primeiro em uma única plataforma, depois expandir para outras. 
Esse é o estágio na qual se publica o jogo em diferentes 
plataformas. Muitas publishers têm adotado este modelo 
recentemente. 

e Cross-promotion: este é mais um estágio de forte publicidade, 
que possui alto valor agregado, pois nessa etapa poderá 
aprender o que fazer melhor nos próximos jogos, analisando os 
feedbacks recebidos. 

e Updates (atualizações): esse estágio de MVG não é 
obrigatório, tal como qualquer um dos anteriores, mas é 
interessante saber que seu jogo pode ser melhorado com a 
presença de updates, em seus diferentes aspectos. Sem a 
internet, era impossível melhorar o jogo, mas atualmente 
atualizações são bastante frequentes. 


4.2 Como obter mais do mínimo? 


É importante sempre estar disponível para receber feedbacks, até 
mesmo examinando os comentários na Apple Store. Outra boa 
medida é utilizar uma conta no Twitter, com informações importantes 
sobre o jogo. Em suma: ser proativo na hora de procurar 
feedbacks. 


Lembre-se de que que as pessoas têm mais chance de oferecer 
feedbacks quando algo está funcionando mal no jogo. Procure 
comparar os feedbacks com a visão inicial do jogo. Uma frase que 
considero importante ter em mente sobre MVPs (no nosso caso, 
MVGs e protótipos) foi escrita por Eric Ries (2011), autor do The 
Lean Startup: 


"O mínimo produto viável é aquela versáo de um produto novo 


que permite a equipe coletar o máximo de aprendizado sobre os 
clientes com o mínimo de esforco." 





Agora vem a ideia de quáo mínimo o "MVP" deve ser? Segundo 
Ries (2011): "Provavelmente bem menor do que o que vocé pensa.' 
Será que essa ideia também se aplica aos jogos? Acredito que sim, 
especialmente quando consideramos as etapas descritas 
anteriormente. Se seu jogo possui uma feature que pode ser cortada 
e seu jogo continua viável, provavelmente ela náo faz parte de seu 
MVP. No caso do Super Mario Brothers, qual seria o MVG? 


$ 





Figura 4.2: Imagem da primeira versão de Super Mario Bros. Fonte: 
www.goliath.com/interest/super-mario-bros/ 


No mínimo jogo viável do Super Mario, quais são as features que 
precisamos? É provável que a maior parte das pessoas pensaria em 
cogumelos, yoshi, koopas, canos, flores de fogo, blocos escondidos, 
mas certamente a resposta é não para todos os itens mencionados. 
As features mínimas são caminhar , pular e, quem sabe, cair nos 


fossos , em um único level. Se isso estiver divertido e empolgante, 
outras features podem ser adicionadas para complementar a 
experiência do jogo. 


Não acredita que isso possa ser um MVG? Tenho alguns 
exemplos que são isso em modo auto-run: Canabalt, Jetpack 
Joyride, Tomb Runner, Temple Run, Subway Surfers, Ski Safari. É 
necessário testar as fundações do jogo antes de incluir 
conteúdo, pois isso facilita o feedback sobre o básico. 


E quanto a um RPG como Final Fantasy? O core do jogo se 
resumiria ao sistema de batalhas, que pode ser visto, de maneira 
semelhante, em muitos outros jogos, como no Pokémon Red/Blue. 
As pessoas jogavam Pokémon e Final Fantasy para divertir-se com 
batalhas Pokémons e com batalhas de pessoas. Se a batalha for 
ruim, o resto do jogo não será interessante e, sendo assim, o jogo 
tem de ser bom sem gráficos de qualidade, bastam blocos com 
nomes e cores. 


4.3 Como perceber se o jogo não é viável? 


Uma etapa muito importante é reconhecer quando seu jogo não é 
viável. Talvez seja uma das decisões mais difíceis para as 
desenvolvedoras, mas é muitas vezes necessária. Ninguém quer 
passar dois anos desenvolvendo duas mil features e descobrir que o 
jogo não é divertido. 


A seguir, apresento algumas ideias de maneiras para medir 
MVPs/MVGs/protótipos que parecem interessantes para as mais 
diversas aplicações: 


e Exploding Kittens (gatinhos explosivos): todos nós gostamos 
de jogos de tabuleiro, acho que fazem parte da nossa infância, 
pois eles nos permitem interagir com outras pessoas, 
especialmente quando eles combinam gatinhos e granadas. 


Jogos de tabuleiro são produtos de alta produção, da arte ao 
game design e à manufatura. Portanto, é preciso saber desde o 
início se as pessoas vão se interessar no produto que estamos 
desenvolvendo. Além de querer recuperar seu investimento, 
você quer um pouco de lucro. Uma ótima maneira de 
determinar se sua ideia vale a pena é iniciando uma campanha 
kickstarter, com vídeos, blog posts, Twitter, forms etc. Isso lhe 
permitirá verificar se sua ideia tem falhas. 

Formulários de inscrição: uma boa maneira de começar seu 
projeto é criando uma página com a descrição de sua ideia e 
um formulário de inscrição que permita às pessoas entrarem 
para participarem de uma lista de e-mails, receberem updates, 
oferecerem feedbacks e sugestões, e receberem notificações 
quando o jogo for lançado. Quem sabe permitir um early 
access? Quem sabe também medir o interesse das pessoas? 
Devaneios no Twitter: mostrar artes conceituais e ideias de 
game design pode dar ideias para outras pessoas, mas também 
pode permitir que você receba ótimos feedbacks. Quem sabe 
divulgar outras informações também? 

Cardboard de fato: essa ideia não serve para todos os jogos, 
mas serve para muitos. Um jogo de tabuleiro inspirado no jogo 
a ser desenvolvido pode ser um bom começo para definir 
mecánicas, features e explorar nossa criatividade, quem sabe 
até para uma ideia de projeto que possa ser vendida? Mas a 
lição mais importante será verificar se sua ideia é boa e vale a 
pena tentar colocá-la em prática. 


4.4 Pensando no mais simples primeiro 


Uma boa forma de começar o desenvolvimento de jogos é pensar 
no que é mais simples de fazer em um MVG e procurar definir seu 
objetivo. Ao nosso ver, uma boa lista de como começar a 
desenvolver jogos via MVG é passar pelas etapas a seguir, 


identificando o que seria o MVG de cada uma. A lista vai do mais 
simples ao mais difícil, na opiniáo da autora: 


Jogos de corrida: Need for Speed; 

Top down shooters — Jogos de tiro com a cámera ortogonal ao 
campo: Halo Spartan Assault; 

Plataforma 2D: Mário; 

Quebra-cabecas: Tetris; 

Plataforma 3D: Mirror's Edge; 

FPS — Tiro em primeira pessoa: Call of Duty; 

JRPG — RPG Japonés: Final Fantasy; 

Jogos de luta: Street Fighter; 

Action Adventure — Jogos de ação e aventura: Tomb Raider; 
RPGs genéricos — Skyrim; 

RTS — Jogos de estratégia em tempo real: Age of Empires; 


Pense nos MVPs (no nosso caso, MVGs e protótipos) conforme 
a figura seguinte. MVPs devem ocorrer de forma incremental, de 
forma que cada MVP dé retorno. 





MVP 7 MVP 8 


Figura 4.3: Exemplo de MVP. Fonte: www.caroli.org/produto-viavel-minimo-mvp/ 





4.5 MVP Canvas para Lean Game Development 


MVP Canvas é um modelo para validar e/ou esclarecer ideais de 
produtos. Ele foi desenvolvido a partir do Lean Startup e é um cartáo 
visual que descreve os elementos de um MVP, como visáo, 
hipóteses, métricas, features, personas, jornadas e até financas 
(http://www.caroli.org/the-mvp-canvas/). Portanto, pense o MVP 
Canvas da seguinte forma: 


e Personas e plataformas: para quem é esse MVG? 

e Jornadas: quais usuárias seráo beneficiadas por este MVG? 

e Visão do MVG: qual a visão para este MVG? 

e Features: o que será construído neste MVG? O que será 
simplificado neste MVG? 

e Custo e agenda: qual será o custo e qual será a agenda deste 
MVG? 

e Declarações obtidas: quais aprendizados desejamos obter 
com esse MVG? 

e Métricas de validação de hipóteses: como vamos medir os 
resultados do MVG? 


Uma das coisas importantes que se pode aprender com esse 
sistema é a ideia de Build, Measure, Learn, que representa a ideia 
de desenvolver, medir o resultado para poder melhorar, aprender 
sobre o que foi desenvolvido, e assim conseguir construir algo 
melhor. 


Nesse caso, o MVP passa a ser medido, construído e "estudado" a 
partir de um modelo simples de idealização. Uma forma de construir 
e pôr em prova o MVG é com a seguinte linha de pensamento: 


e Nós acreditamos que ... [visão do MVG] 
e Vai conseguir... [resultado esperado] 


e Sabemos que isso aconteceu com base em... [métricas 
para validar as hipóteses do jogo] 





Nosso EXEMPLO 


e Nós acreditamos que as mecánicas fundamentais do jogo 
bem estruturadas. 
e Vão conseguir proporcionar entretenimento melhor que um 


jogo cheio de features. 

e E saberemos que isso aconteceu com base no tempo médio 
de jogo por usuária e em feedbacks que retratem a 
qualidade de nossas mecânicas. 





4.6 Como ficariam os MVGs e os protótipos para 
o Super Jujuba Sisters? 


Considere o jogo descrito na seção anterior e suas especificações. 
Uma das formas de entender quais são as features mais 
importantes é solicitando que a equipe coloque todas elas dentro de 
um canvas e, depois, de forma colaborativa, organize-as em ordem 
de importância, posicionando-as em um canvas de gráfico, no qual o 
eixo das ordenadas corresponde à prioridade no quesito jogo e o 
eixo das abscissas indica a dificuldade técnica em implementar as 
features. 


A partir disso, pode ser construída a lógica de evolução dos MVGs. 
A figura a seguir demonstra esse conceito. A segunda figura indica 
como sequenciamos as features de uma forma a estabelecermos a 
separação dos protótipos e MVGs. 






Valor 
(Feature) 


Custo 
(Tempo, dificuldade de executar, dificuldade de validar) 


Figura 4.4: Canvas mostrando a relacáo entre prioridade e dificuldade técnica 


Sequenciador 


Cada uma das sequéncias de cores representa um MVP 





Figura 4.5: Sequenciador das features para gerar os MVPs e MVGs 


Como dividimos nossos MVGs? 


1. Protótipo 1: 


o Mecánicas de Jogo para caminhar, pular e cair. 
o Artes prototipadas para personagem principal e mapa. 
2. Protótipo 2: 


Mecânicas de renascer, matar e morrer. 
Mecânica de inimigo 1 da gangue Xandra. 
Artes prototipada para inimigo 1. 

o Arte para a personagem principal. 
3. Protótipo 3: 


o oo 


o Mecânica de poder especial. 
o Arte para poder especial. 
o Arte inimigo 1 

4. Protótipo 4: 


o Arte para novo mapa. 
o Mecânica de blocos escondidos. 
5. Protótipo 5: 


o Mecânicas inimigo 2. 
o Arte prototipada do inimigo 2. 
6. Protótipo 6: 


o Arte do cenário 3. 
o Mecânica de blocos em movimento. 
7. Protótipo 7: 


o Mecânicas para Marcibal. 
o Arte prototipada para Marcibal. 
8. Protótipo 8: 


o Comportamentos de Marcibal. 
o Arte do cenário de Marcibal. 


Separando os MVGs 


Dessa forma, separamos os MVGs da seguinte forma: 


MVGO: Board game para testar mecánicas e layouts. 
MVG1: Protótipo 1 + Protótipo 2 

MVG2: MVG1 + Protótipo 3 + Protótipo 4 

MVG3: MVG2 + Protótipo 5 + Protótipo 6 

MVG4: MVG3 + Protótipo 7 + Protótipo 8 


Agora sabemos o que é um MVP no caso de jogos, como este 
conceito pode ser aplicado a jogos, como eles são gerados, e como 
eles podem atuar do ponto de vista de desenvolvimento e de 
entrega contínua. Aprendemos como métricas de MVGs e a 
importância de hipóteses para guiá-los através das iterações. 


Entendemos melhor as funções e os papéis das pessoas envolvidas 
na visão gerada pelos MVGs. E por último, vimos um exemplo de 
separação de MVGs aplicada a games. Mas sabemos que 
precisamos de hipóteses e métricas para nos permitir medir, analisar 
e nos guiar através de todo o curso do desenvolvimento. 


CAPÍTULO 5 
Como gerar hipóteses? 


Junto com a geracáo dos MVGs, as hipóteses sáo uma das etapas 
mais importantes da Inception, pois sáo elas que guiaráo e mediráo 
nosso produto ao longo das iterações. Os MVGs determinam qual 
conjunto de atividades deve ser feito, enquanto as hipóteses nos 
permitem validar se nossos MVGs possuem o efeito desejado e que 
a visão do produto está sendo realizada. 


A primeira geração de hipóteses é bem intuitiva, pois ela faz parte 
da Inception (etapa inicial do desenvolvimento). Mas para que 
servem as hipóteses”? Sua primeira função é ajudar a desenvolver o 
design de jogo, a narrativa e, o que é mais importante, ajudar a 
validar o MVP. 


Porém, a principal diferença de hipóteses e histórias é que as 
histórias servem para guiar o desenvolvimento, mas hipóteses 
servem para retroalimentar o backlog. Vamos utilizar os exemplos 
de histórias geradas na Inception para criar hipóteses. 


Relembrando das personas apresentadas no capítulo de Inception, 
temos dois casos que queremos utilizar como guias para nossa 
geração de hipóteses. As jornadas de personas e as histórias 
desenvolvidas eram: 


Jornada de personas: 


e Como Guilherme, quero que o jogo me lembre dos tempos 
antigos do videogame e, para isso, quero uma experiência tipo 
Mario 2.0. 

e Como Carlita, quero poder fazer a princesa salvar o dia, 
portanto, quero que a personagem principal seja feminina. 


Histórias: 


e Para Guilherme, é importante pular, caminhar e cair. 

e Carlita quer que a Jujuba seja uma personagem forte e, assim 
como em Frozen (desenho da Disney), as coisas girem em 
torno de irmãs. 


Com base nessas histórias e jornadas, concluímos as seguintes 
hipóteses: 


Hipóteses: 


e Nós acreditamos que, construindo as funcionalidades de 
caminhar, pular e cair para o público de jogadores, teremos 
como resultado um jogo com as mecânicas básicas fortes. 
Sabemos que fomos bem-sucedidas quando tivermos 
feedbacks positivos dos testes manuais e de terceiros, por meio 
de nossa demo. 

e Nós acreditamos que, ao construir uma personagem feminina 
forte, não estereotipada e com funcionalidades interessantes, 
poderemos atingir o público feminino, que por isso se 
empolgará com nosso jogo. Sabemos que fomos bem- 
sucedidas quando muitas meninas estiverem comentando no 
nosso feed. 


Com esses modelos que propusemos, como ficaria um modelo 
padrão para desenvolvimento de hipóteses? Um modelo bem 
comum em Inceptions é o seguinte: 

Nós acreditamos que (GOTHELF, 2013): 

construindo a funcionalidade [nome da funcionalidade] 

para o público [público-alvo proposto] 


atingiremos [resultados esperados] 


Saberemos que fomos bem-sucedidas quando tivermos [o sinal 
do mercado esperado] 





5.1 E quando as hipóteses náo forem criadas a 
partir da Inception? 


As hipóteses servem para nos auxiliar a fazer validacáo em cada 
ciclo. Sáo fundamentais para realizar as etapas de medir e analisar, 
pois sáo elas que determinam o que temos de avaliar. Por exemplo, 
se recebermos feedbacks negativos do público feminino sobre a 
personagem, devemos parar para analisar onde e em que ponto nos 
encontramos, e procurar desenvolver novas ideias utilizando os 
feedbacks. 


Alguns exemplos de possíveis medidas: 


e Quando percebemos que o público feminino se sentiu ofendido 
pela personagem, temos de verificar quais foram as críticas 
(exemplos: roupas, armadura inexistente, desproporcionalidade 
do corpo, história absurda, falta de história), verificar onde 
erramos e pensar em novas soluções para gerar novas 
hipóteses. 


e Quando percebemos que o público reclamou que a mecánica 
de pulo é esteticamente feio e que dá impressão de que a 
personagem está se movendo bruscamente para cima e para 
baixo. Será que se trata de um problema de como melhorar a 
animação? Ou será que se trata do problema de não parecer 
real? Ou será que não está adequada às necessidades do 
jogo? Nesse ponto, é preciso verificar em que etapa erramos e 
propor novas modelagens. 


e Se percebermos que o público reclamou que a primeira fase é 
muito legal, mas as outras são exatamente iguais, o que torna o 
jogo pouco interessante, como podemos tornar as demais fases 
mais interessantes? Novos personagens? O clima do jogo está 
mal concebido? Há dificuldades adequadas no cenário? É 
preciso examinar o que está faltando e gerar novas ideias para 
tornar a experiência da usuária mais interessante. 


Esses exemplos mostram a necessidade de elaborar hipótese para 
garantir que atingimos nossos objetivos. 


No capítulo Medir e analisar, falaremos bastante sobre 


feedbacks. Pode valer a pena dar uma olhada na secáo de 
feedbacks agora. 





Neste capítulo, entendemos o que sáo histórias ou jornadas, 
personas, e como extrair hipóteses através disso, e vimos como as 
hipóteses sáo grandes fontes de apoio aos MVGs e como podemos 
gerar essas hipóteses. Entendemos também como gerar ideias, e 
como elas funcionam em um ciclo de muitas iterações. 


Entretanto, agora precisamos entender as coisas do ponto de vista 
mais prático e menos teórico, de modo que tenhamos recursos para 
nos guiar pelas próximas etapas do desenvolvimento lean, como 
desenvolvimento guiado a testes e integração contínua (como o 
design e o build). 


CAPÍTULO 6 
Desenvolvimento Guiado a Testes 


Ainda que a literatura sobre este tema seja extensa e qualificada, 
vale a pena tomarmos este capítulo para nos aprofundarmos nos 
tópicos apresentados, já que é um assunto de extrema importância. 


DEFINIÇÃO 


O TDD (Test-Driven Development, ou Desenvolvimento Guiado a 
Testes) é um estilo de desenvolvimento de software apresentado 
principalmente pelo método ágil Extreme Programming (XP), de 
Kent Beck. A prática envolve a implementacáo de um sistema a 


partir dos casos de teste de um objeto. Escrevendo casos de 
testes e, consequentemente, os testes, se implementa o objeto a 
partir da demanda de cada teste. Deve se escrever um teste e, 
logo após, implementar sua solução, evitando escrever diversos 
testes e códigos ao mesmo tempo. Assim, temos um ciclo 
contínuo de pequenas iterações. 





6.1 Então, o que é o TDD? 


TDD é um estilo de desenvolvimento de software no qual você 
possui a sua disposição: 


e Um conjunto enorme de testes feitos por quem desenvolveu o 
código. 

e Nenhum código em produção sem que ele tenha testes, e tenha 
sido testado. 

e Um método no qual se escreve o teste primeiro. 


e Código escrito de forma que seu único objetivo seja passar no 
teste de forma simples. 


Podemos resumir os princípios da seguinte forma: a desenvolvedora 
do código escreverá os testes, pensando antes quais sáo os testes 
necessários e como eles devem ser ordenados, para entáo 
implementar códigos baseados neles, de tal forma que o código 
somente será escrito após o teste e concebido de forma a apenas 
passar o teste previamente escrito. Uma das vantagens desse 
método é que ele implica no "Pense antes de desenvolver". E claro, 
uma especialista em testes pode ser consultada. 


Aspectos importantes do TDD sáo: 


1. Rodar o código frequentemente, pois isso permite uma 

visualizacáo do estado geral do código. 

2. Manter todo o código testado nas menores unidades 
unitárias. Quanto mais simples e unitário for o código, mais fácil 
será de corrigir problemas de build e de testes que falham. 

. Tratar testes que falham como builds quebrados. 

. Manter os testes simples, pois testes complexos podem náo 
estar testando as unidades desejadas, ou estar atuando como 
testes unitários (TDD pode envolver muitos mais testes que os 
unitários também). 

5. Testes devem ser independentes uns dos outros, pois 

devem testar unidades/ features! componentes isolados. 


E 0 


Ao nosso ver, as vantagens do TDD sáo inúmeras. Eis algumas: 


e O programa se torna mais compreensível e mais fácil de 
implementar. 

e Permite soluções mais simples. 

e Apresenta muito menos defeitos. 


O design de código a partir de TDD pode fazer com que o código 
seja formulado de maneira mais elegante. Além disso, pode 
funcionar muito bem como uma forma de documentação. Uma 
coisa importante de salientar é que é muito comum que as pessoas 


confundam o conceito de TDD com o de testes unitários. Daqui em 
diante, para simplificar, vamos empregar a seguinte expressáo: 


TDD > TESTES UNITÁRIOS 








Essa formulação torna a ideia bem mais clara. O TDD utiliza testes 
unitários para fazer o design e o desenvolvimento do código. No 
entanto, o uso de testes unitários no seu código não torna seu 
desenvolvimento guiado a testes, e a presença de testes é apenas 
parte do TDD. A figura a seguir apresenta um ciclo comum de TDD. 


1. Escreva um bom teste que o 


código falhe 
E 
-—D 


2. Escreva o mínimo de código 
para o teste passar (sem quebrar 
outros testes) 











Refatore 





3. Elimine a redundáncia 


Figura 6.1: Ciclo do TDD 


Dessa forma, o desenvolvimento guiado a testes ocorre da seguinte 
forma: 


e Escrever o teste: sem um teste, não sabemos por onde 
começar. 

e Rodar o teste e vê-lo falhar: de que adianta um teste que já 
sabemos que vai passar? Ele tem de falhar. 


e Escrever o código: agora escreva o código mínimo para 
aquele teste. 

e Rodar o teste e vê-lo passar: "Oba! Agora ele passou", e 
nosso código parece correto. 

e Refatorar: certamente existem coisas que podem ser 
melhoradas no código, "Vamos melhorá-las!". 

e Iterar: próximo teste. 


6.2 Testes são bons, mas por que existe tanto 
código mal testado? 


Creio que a grande maioria das empresas, em quase qualquer área, 
considera os testes como algo positivo. Ninguém quer um material 
de colete a prova de balas que nunca foi testado, assim como 
ninguém quer um software que não foi testado. Então, por que 
existem tantos softwares mal testados”? 


Simplesmente porque existe uma série de problemas com a 
abordagem tradicional dos testes: 


e Se os testes não forem abrangentes o suficiente, erros podem 
ser colocados em produção, gerando efeitos devastadores. 

e Testes são geralmente feitos após o código ter sido escrito. 
Quando você já encerrou sua atividade de programação, voltar 
a um programa anterior pode ser custoso. 

e Geralmente, testes são escritos por programadoras diferentes 
daqueles que escreveram o código. Como elas podem não 
compreender o código em sua totalidade, pode ocorrer que 
cometam erros de compreensão e de abordagem nos testes. 

e Se quem escreve o teste se baseia em documentação ou 
outros artefatos além do código, qualquer atualização de 
artefatos pode tornar o teste obsoleto. 

e Se os testes não forem automatizados, eles não serão 
executados com frequência, de forma regular, ou então não 


exatamente da mesma forma. 

e Consertar um problema em um determinado lugar pode gerar 
um problema em outro lugar. Nesse caso, se a estrutura dos 
testes náo for abrangente, ela náo detectará esse novo 
problema. 


TDD resolve todos estes problemas: 


e À programadora escreve o teste antes do código ser escrito. 
Neste caso, o código é baseado nos testes, garantindo 
testabilidade, abrangência e sincronia entre teste e código. 
Além disso, eles são automatizados e rodados com frequência. 

e Permite que, quando um bug for encontrado, ele seja 
rapidamente reparado; procedimento este que estará garantido 
pela abrangência dos testes. 

e Quando o código é entregue, os testes são entregues juntos, 
facilitando que futuras mudanças e extensões sejam feitas de 
forma simples. 


6.3 E como aplicar isso a jogos? 


Sabemos que as empresas de jogos costumam não acreditar que 
fazer TDD seja possível — mentalidade compartilhada por suas 
desenvolvedoras. Claro que entendemos que existem grandes 
diferenças entre software corporativo e software de jogo, mas boas 
práticas, testes e tudo mais podem sim ser aplicados a jogos. 


Um exemplo dessa mentalidade anti-ágil são os comentários de Rob 
Galanakis (2014), sob o nome de Agile Game Development is Hard: 


e Jogos são arte e arte não pode ser iterada como outros 
softwares. Sei que a indústria de jogos prefere se comparar 
com a de cinema do que com a de software, e concordo que 
jogos sejam arte, mas arte também pode ser feita em pequenos 


passos. A figura no final desta lista mostra que náo é bem 
assim. 

Jogos exigem muita infraestrutura para tornar qualquer coisa 
jogável. Jogável para uma usuária final, talvez. Mas lembre-se 
de que nem toda entrega precisa ser para uma cliente final. 
Jogos querem que usuárias fiquem o máximo de tempo jogando 
e não poupem tempo. Aqui o objetivo seria fazer a equipe de 
desenvolvimento poupar tempo, o jogo em si não tem tanto 
impacto. 

Jogos são impossíveis de testar, ou significativamente mais 
difíceis. Acho que ficará bem claro posteriormente que jogos 
são e devem ser testados. 

Entregar contínua confunde a indústria, pois jogos são 
tradicionalmente completos. Mudança de cultura sempre é 
necessária; se acomodar nunca é bom. 


Iterativo 















Incremental 


-w EA 


Figura 6.2: Métodos ágeis aplicados à arte. Fonte Jeff Patton: 
http://jpattonassociates.com/dont know what i want 





No Anexo B — Engines, falamos de algumas engines, e 
posteriormente falaremos de algumas formas de se aplicar testes a 
jogos. Porém, acho importante apresentar algumas soluções viáveis 
para aplicar TDD agora. 


e Frameworks como Pygame (www.pygame.org/ OU pip install 
pygame ) e Monogame (www.monogame.net/) permitem ótimas 
soluções no uso de testes, especialmente por sempre estarem 
integrados às últimas versões de suas linguagens. Além disso, 
todo o jogo é feito via código, o que elimina a dificuldade de 
testar componentes. 

e A Unity foi uma das primeiras engines a desenvolver um asset 
para testes. Infelizmente, ele tem pouca manutenção, o Unity 
Test Tools. Este permite uma série de testes, mocks e testes 
em nível de componentes. Costuma ser difícil utilizar TDD com 
esse asset, mas, com criatividade e esforço, se consegue 
aprender. 

e A Unreal é uma engine em C++ de código aberto. Com um 
pouco de dedicação da equipe de desenvolvimento, é possível 
integrar bibliotecas de teste. 

e A CryEngine recentemente mostrou interesse em possibilitar a 
integração com sua engine. Eles disponibilizaram uma palestra 
chamada AAA Automated Testing (CARUCCI, 2009a) em seu 
site Crytek (CARUCCI, 2009b). 

e Nas outras engines, a solução pode ser relativamente simples. 
Crie uma cena que conterá vários testes. Com prefabs vazios, 
comece a gerar condições de teste. A partir de um script de 
testes, que você desenvolveu, anexe a cena e teste 
comportamentos específicos de seus prefabs/scripts. 


PREFABS são componentes pré-fabricados pela desenvolvedora, 
que permitem a reutilização desses componentes em outras 


partes do jogo. Exemplos são objetos de cenário, inimigos, 
jogadoras que podem ser instanciadas etc. 





Alguns exemplos de testes na Unity: 


e Unite Boston 2015 - Unity Test Tools: Test automation in Unity 
now and in the future — https://youtu.be/wJGUc-EeKyw 

e Unity Test Tools: Test automation in Unity now and in the future - 
Unite Europe 2015 — https://youtu.be/ OYojVTagxY 


Lembre-se, jogos costumam ter códigos bastante complexos e 
muitos componentes que vão além de códigos. Dessa forma, é 
importante sempre ter em mente qual o teste mais simples que 
posso fazer, e como fazê-lo passar da forma mais simples possível. 


Já me deparei com situações de desespero ao ter de testar 
componentes do ponto de vista visual e de forma automatizada, 
mas a solução foi bem simples: criei uma cena que executava 
automaticamente e todos os componentes presentes nela 


começavam vazios. Essa cena possuía um único script que 
gerenciava os testes. À medida que escrevia cada novo teste, os 
componentes iam evoluindo, ao ponto de eu conseguir criar 
prefabs simples e ideais para as aplicações que necessitava. 





TDD para jogos tem desafios que a maior parte dos softwares não 
possuem, como a grande variedade de plataformas (Mac, Windows, 
Linux, Xbox, Nintendo, Playstations, ¡OS, Android). Assim, há a 
necessidade de rodar os testes unitários em cada uma das 
plataformas que queremos que nosso jogo rode. Normalmente, 
mantemos vários builds e checamos se estes quebram os testes e 
em quais casos específicos isso aconteceu. 


Um outro grande desafio encontrado é a questão de testar os 
gráficos. É uma boa prática de engenharia de software manter todo 
o código relacionado a gráficos em um único módulo, o que contribui 
para facilitar os testes dos outros módulos. Utilizar engines pode 
tornar o TDD inviável, já que as maiores não são amigáveis ao TDD 
— apesar de algumas delas, como Unity e Cry, terem começado a 
se preocupar com isso. 


Aleatoriedade é algo indispensável em jogos. Por exemplo, é 
impossível prever qual som de caminhar deveria ser tocado; e fazer 
testes em cima de coisas aleatórias é bastante complexo. Uma das 
maneiras de resolver a aleatoriedade nos testes é tentar extraí-la ao 
máximo dos que estáo sendo testados. Quem sabe passá-la como 
argumento? Há uma clara relacáo entre a utilizacáo de testes e a 
diminuicáo de bugs. 


6.4 Próximos passos para tornar o TDD melhor 


O TDD foi desenvolvido para ser utilizado com uma série de práticas 
que agregam valor ao desenvolvimento. A seguir, veremos algumas 
delas. 


Refatoracáo 


É o processo de fazer mudanças em códigos existentes e 
funcionais, sem contudo modificar seu comportamento externo. 
"Mudar como o código faz, mas não o que ele faz." O objetivo é 
melhorar a estrutura interna do código, tornando-o mais legível e 
possivelmente mais performático. 


1. Depois de fazer o código mais simples para o teste passar, 
refatoramos para limpá-lo, principalmente diminuindo as 


duplicações. 
2. Garantir que a refatoração não quebre os testes. 





E quando refatorar: 


e Quando houver código duplicado. 
e Quando percebermos que o código não está claro ou legível. 
e Quando detectarmos um código potencialmente perigoso. 


Alguns exemplos de refatorações importantes são: 


e Extrair classes: quando uma classe é muito grande ou seu 
comportamento deixa de ser claro, vale a pena separá-la em 
duas ou mais, de modo que comportamentos semelhantes 
estejam juntos. 

e Extrair interfaces: facilitam o uso de mocks, pois representam 
o comportamento de grupos. 

e Extrair métodos: aplica-se quando um método é muito longo, 
ou com uma lógica muito complexa. Facilita a compreensão dos 
métodos. 

e Introduzir variáveis autoexplicativas: quando precisamos de 
variáveis que não são claras em relação à sua função ou o 
porquê estão ali, é bom extraí-la para uma constante que 
explique sua função. 

e Procurar identificar padrões. 


Pair Programming 


Por que a programação em pares (pair programming*) está inclusa 
em TDD? Não está diretamente, mas a ideia é que faça parte das 
práticas de programação. E isso porque a programação em pares 
melhora o seu desempenho no TDD. Alguns de seus benefícios são: 


e Aumento da concentração das programadoras, já que 
melhora a comunicação entre todas as partes envolvidas, 
especialmente facilitando a identificação e a resolução de 
lacunas, além de estimular discussões criativas. 

e Redução de defeitos, pois ajuda a tornar o código mais 
simples e as revisões mais eficientes. 

e Continuidade do negócio, já que o aumento de comunicação 
reduz o impacto da saída de um membro do projeto. Uma vez 
que nem tudo saí sempre perfeito, pode ocorrer que seja 
preciso enfrentar alguns desafios com relação ao pair 
programming, como infraestrutura de trabalho, já que montar 
equipes pode ser bem complicado, especialmente em 
empresas de pequeno porte. Além disso, se sua equipe não 
possuir configurações idênticas para todas, tais como IDEs e 


editores, pode ser bem difícil implementar o pair programming. 
Também é preciso levar em conta a fadiga, pois é comum 
encontrar pessoas exaustas depois de horas de pair 
programming. 

e Redução dos problemas de conflitos entre egos. Talvez uma 
das maiores dificuldades de muitos pairing é a falta de 
comunicação e de humildade na hora de discutir. É comum que 
discussões construtivas se transformem em argumentações 
agressivas, e isso pode vir a ser fatal para o pair programming. 
É importante lembrar de que, como tudo é feito em conjunto, 
então é indispensável valorizar o par e não os indivíduos. Outra 
coisa que pode ser muito benéfica para o pairing é o feedback. 


Algumas dicas para o pair programming propostas por Tarso Aires 
(2015): 


e Não centralize o driving: o membro do par que se sente mais 
confortável com o ambiente de desenvolvimento tende a 
centralizar o driving, em parte porque a outra parceira pode ter 
a sensação que vai prejudicar o pairing quando fizer o driving. É 
bom definir previamente um intervalo de tempo para a troca de 
driving. 

e Gerenciem o foco juntos: ter focos diferentes é algo 
extremamente comum. Caso isso se torne um problema, a 
parceira mais focada deve atrair o foco da menos focada. Pode 
ser muito complicado para a parceira menos focada recuperar o 
foco sozinha. Técnicas como Pomodoro podem ajudar — ela 
consiste de pequenos intervalos para relaxar. 

e Evitem trabalhar sozinhas: às vezes, uma das pessoas do par 
pode ter de se ausentar; esse caso é útil esperar a sua volta. 
Aproveite a oportunidade para fazer coisas não relacionadas ao 
trabalho. 

e Procure intercalar momentos de concentração e de 
desconcentração: foco é fundamental, mas seu excesso pode 
ser prejudicial. Lembrem-se de que não somos robôs e que 


precisamos de descanso. Jogue videogames, tome um café e 
fale da vida, ou tire até mesmo uma soneca de 15 minutos. 

e Celebrem as conquistas: ao final de cada etapa ou atividade, 
é muito gratificante e empoderador parar e contemplar o que foi 
feito. Celebrem! 

e Sincronia: é natural uma pessoa ter mais contexto da atividade 
a ser desempenhada. Isso pode provocar uma diferença no 
ritmo no qual as coisas serão realizadas, prejudicando o pairing. 
Perceba essas diferenças, adapte-se ao ritmo de seu colega, 
explique suas ideias e contexto quantas vezes for necessário. 
Comunicação é essencial. 

e Transmita o contexto adequadamente: é importante garantir 
que ambos os membros do par tenham um vocabulário comum. 
Se necessário, desenhe diagramas e tente sempre explicar da 
forma mais simples e direta. 

e Saiba lidar com divergências: as divergências acontecem o 
tempo todo durante o pareamento. Nesses momentos, é 
importante parar e ouvir tudo o que a outra tem a dizer, 
respondendo da forma mais serena e respeitosa. Se for 
necessário, chamem uma terceira pessoa para auxiliar na 
solução do impasse. 

e Disponha-se a aprender e ensinar: tenha consciência de que 
você pode contribuir mesmo que seja nova no projeto, da 
mesma forma que você tem muito espaço para aprender coisas 
novas. Apresente conceitos de forma gradativa e conduza seu 
par à solução de maneira sutil e aberta. Ouça com atenção o 
que lhe estiver sendo ensinado. 

e Troquem feedbacks: não precisa ser conversas formais. É 
interessante fazer isso enquanto as memórias estiverem 
frescas. Pode ser uma conversa de 15 a 30 minutos, ou troca 
de anotações em algum lugar adequado. 


O exemplo mais comum de programação em pares é duas pessoas 
dividirem os acessórios e o monitor de uma CPU, e trabalharem de 
forma combinada. Outra maneira bastante comum é usando 

ferramentas, como Screenhero, que permitem que a pessoa remota 


edite e altere o ambiente de desenvolvimento através de uma tela 
compartilhada. 


A frase que resume pair programming é: "Duas cabecas pensam 
melhor do que uma”. 


Caso você queira estudar mais sobre TDD, consulte as 
referências na bibliografia. 





Este capítulo nos permite entender qual será a mentalidade da 
equipe quando for pensar em ferramentas para o desenvolvimento 
de jogos, pois o suporte a estas técnicas é indispensável para 
garantir qualidade. Além disso, vimos sobre as etapas do 
desenvolvimento guiado a testes e técnicas para melhorar o 
desempenho da equipe, como pair programming. 


Infelizmente, somente teste bem testado não garante qualidade 
total, já que se o código não estiver sempre na última versão, os 
testes poderão estar quebrados, ou o build do jogo não funcional. É 
neste momento que pensamos em integração contínua. 


CAPÍTULO 7 
Integracáo contínua 


O principal objetivo de integracáo contínua é encontrar bugs o 
quanto antes. De forma simplificada, ela passa pelas seguintes 
etapas: 


Bug Tracker — Ferramenta para identificar bugs. 

Source Control — Para comitar o código em alguma 
ferramenta de versionamento de código. Uma ferramenta que 
nos permite verificar o estado atual do código e todas as 
mudanças que ele já sofreu. Pode ser usado em associação 
com o build agent. 

Build Agent — Ferramenta que gera o build do código. 
Geralmente, é um conjunto de comandos em um ambiente, 
como Jenkins, com o objetivo de disponibilizar builds de forma 
automática. 

Testes unitários — Neste caso, acho que algo que pode 
auxiliar muito são testes de mutação, que introduzem pequenos 
erros e variações no código a fim de determinar a abrangência 
dos testes. 

Testes de funcionalidade automatizados — Testes que 
checam se todas as funções e features estão funcionando de 
forma correta, e se nenhuma delas está defeituosa. 

Deploy — Liberação de um build para uso, update, teste 
manual, entre outros. 


Idealmente, a integração deve ocorrer no mínimo uma vez por dia e, 
se for possível, mais vezes, tanto melhor. Cada integração de 
código é verificada por um build automático, o que facilita a 
detecção de problemas. Além disso, a prática ajuda a identificar de 
forma rápida onde está o erro. 


"CI não nos livra de bugs, mas torna achá-los e remové-los 


infinitamente mais fácil". — Martin Fowler 





Como a integracáo ocorre com frequéncia e procurar bugs torna-se 
um trabalho mais simples, as desenvolvedoras possuem mais 
tempo para desenvolver novas features. Além disso, permite que o 
projeto tenha maior clareza a respeito do tempo de 
desenvolvimento, já que será necessário despender menos tempo 
corrigindo bugs. 


Algumas vantagens da Cl (Continuous Integration) sáo relatadas a 
seguir: 


Não existirão mais integrações longas e complexas, já que o 
código é integrado a todo momento e cada integracáo é 
pequena. 

Aumentará a visibilidade de cada etapa, permitindo uma melhor 
comunicação. Todos podem acompanhar como as colegas 
estão desenvolvendo e em que etapa do desenvolvimento elas 
se encontram. 

Facilitará a identificação de problemas, e de forma rápida, 
permitindo resolvê-los imediatamente. Qualquer problema será 
identificado assim que o código rodar o build automatizado. Se 
gastará menos tempo com debug e mais tempo com features, 
já que os erros serão identificados rapidamente, sem longas 
horas de investigação. 

Aumentará a confiança de que se está construindo um jogo 
com fundações sólidas, já que os testes e a integração contínua 
garantirão que os erros sejam pequenos e identificados 
rapidamente. 

Desaparecerá a tensão e o mistério de ficar esperando para ver 
se o código funciona. Apesar dos builds serem demorados, o 
tempo para consertá-las reduz drasticamente. 


7.1 Como fazer integracao contínua 


Existe uma literatura extensiva sobre o assunto, desde livros sobre 
metodologias ágeis até livros sobre engenharia de software. Mas 
nosso objetivo agora é simplificar tudo isso e mostrar o caminho: 


1. As desenvolvedoras colocam o código em seus workspaces. 

o git clone [url do repositório] — adiciona o código a sua 
workspace. 

o git status — verifica o estado do código. 

2. Quando as modificações estiverem prontas, comitam as 
mudanças no repositório único, geralmente em uma nova 
branch. 

O git checkout -b nova-branch — modifica a branch de trabalho 
para a nova-branch . 

o git add -p ( -p para fazer revisão de todas as mudanças, 

e --al1 para adicionar tudo) — adiciona as mudanças 
ao estado de commit. 

O git commit -m "Aqui vai o comentário" — commit das 
mudancas com comentário. 

O git push [nome-remoto] [branch] ( -f para sobrescrever) = 
envia as mudanças feitas para o repositório. 

3. Realiza-se o merge da branch com o repositório principal. 

o git fetch [remote] [branch] — busca todas as branches do 
repositório e realiza o download de todos commits 
necessários. 

o git merge origin/master — Sincroniza as mudanças com o 
repositório master. 

o em vez dos comandos anteriores pode se utilziar git pull 
[remote] . 

4. O servidor Cl monitora o repositório e procura por mudancas. 

5. O servidor constrói o jogo, e roda os testes unitários e de 
integracáo. 

6. O servidor libera um artefato para teste. 

7. O servidor designa um rótulo para o build da versáo que está 
fazendo. 


8. O servidor informa á equipe o horário no qual o build foi feito 
com sucesso. 
9. Caso o build ou os testes falhem, o servidor avisará a equipe. 
10. A equipe corrigirá o erro. 
11. Itere (continue fazendo Cl). 


MAIS SOBRE O GIT 


Git é um sistema de versionamento de código que possui todo o 
código armazenado em um repositório. Caso algum dos arquivos 
presentes na máquina não sejam necessários para a execução 


do projeto, pode-se utilizar um .gitignore, que os ignora quando 
for passá-los de sua máquina no repositório. 


Mais sobre GitHub pode ser encontrado no livro Controlando 
versões com Git e GitHub, de Alexandre Aquiles e Rodrigo 
Ferreira (2014). 





Responsabilidades da equipe quanto ao Cl 


Apesar de ser a vontade da maior parte dos desenvolvedores, o Cl 
ainda não ocorre sozinho, e na maior parte dos casos não é 
autogerenciado. Para tanto, existe uma série de responsabilidades 
que os membros da equipe devem ter: 


e Manter o código atualizado, cada vez que o código precisar 
ser mexido é importante que as modificações anteriores já 
estejam integradas, especialmente se elas forem correções de 
bugs. 

e Não comitar código quebrado, código quebrado quebra o 
build e o torna um problema em vez de uma solução. 

e Não comitar código não testado, se o código não está 
testado não se pode garantir que ele funcione, e se ele não 
funcionar não teremos um jogo funcionando. 

e Não comitar quando o build estiver quebrado. Quando o 
build está quebrado, o último commit deve ser revertido e 


corrigido. Se ele náo for corrigido, as modificacóes futuras 
permanecerão quebradas e não será possível identificar futuros 
problemas. 

e Não abandonar o build até que o build do jogo esteja pronto. 
Mantenha atenção nele, pois se quebrar, é preciso tomar 
providências. 


E quanto às vantagens de uso de Cl no desenvolvimento de 
jogos? 


Além da grande quantidade de ferramentas de Cl disponíveis e 
compatíveis com engines de desenvolvimento de jogos, temos 
algumas vantagens que são importantíssimas do ponto de vista de 
poupar tempo: 


e Não-programadoras podem testar a atual versão do jogo. 

e Versão de divulgação para a imprensa pronta fica disponível. 

e A publisher consegue acompanhar e identificar o estado em 
que se encontra o jogo. 

e Garantia de que o jogo funciona em diferentes plataformas 

Facilidade para obter o build da versão final. 

Facilidade de arrumar caso a versão final tenha muitos bugs. 


7.2 Versionamento de código 


Versionar o código permite uma série de benefícios, pois cada uma 
das etapas do código está disposta em um sistema que permite 
identificar pontos positivos de versões, reverter e dividir o código. 
Algumas vantagens estão listadas a seguir: 


e Mudou o código, e percebeu que era um erro? Basta reverter. 
Se o commit já foi para o build, é uma boa prática reverter e 
refazer. 


e Perdeu o código e a versão de backup é muito antiga? Basta 
commitar frequentemente. Se os commits forem frequentes, 
não teremos problemas de recuperar código perdido. 

e Precisa verificar diferenças de versões do código? git diff. 
Muitas ferramentas de versionamento permitem verificar as 
diferenças entre o que se está mexendo e o original. Outra 
vantagem é que se pode verificar o log de modificações, 
permitindo identificar quando uma feature foi adicionada. 

e Precisa identificar qual foi a mudança que quebrou o código? 
Facilita a identificação e a correção. "Identificar na plataforma 
de Cl qual foi o commit que quebrou o código." Além disso, 
está relacionado ao item anterior, pois inclui o conceito de 
verificar diferenças. 

e Permite dividir o trabalho sobre o código? Divisão de trabalhos 
é importante para que o desenvolvimento possa ser feito de 
forma conjunta e não sequencial. 

e Quer acompanhar o desenvolvimento do código? Visualização 
do andamento do projeto permite a todo time de 
desenvolvimento verificar o desenvolvimento do jogo, e permite 
pessoas externas ao desenvolvimento verificarem como as 
coisas estão fluindo. 

e Precisa manter diferentes versões de um produto? Muitas 
vezes, é preciso manter build de plataformas diferentes. 
Integração contínua permite fazer isso de forma bastante 
simples. Uma sugestão é o uso de branches. 


É uma boa prática utilizar comentários nos commits que 
identifiquem qual card gerou a modificação e o que foi feito. 


Quando uma branch é criada, ela deve identificar a qual card 
pertence e o que ela fará. 





Todas essas dificuldades podem ser resolvidas com auxílio do 
versionamento. Nossa preferência e sugestão é versionamento por 
Git, como o GitHub. Para UNITY, lembrando de que os cuidados são 


semelhantes em outras ferramentas. Por exemplo, será necessário 
tomar cuidado com os seguintes itens: 


1. Utilize gitignore.io para gerar o seu, evitando enviar centenas 
de arquivos desnecessários. Cuidado com modelos 3D com 
terminação em .obj, pois deve-se retirar o .[00]bj desse 
arquivo. 

2. Editor Settings | Asset Serialization Mode -> Force Text flag — 
Previne que os arquivos da Unity sejam enviados como 
binários, pois isso pode gerar problemas de merge no GitHub. É 
muito complexo realizar merge de sequências numéricas. 

3. Editor Settings | Version Control Mode -> Visible Meta Files — 
Os meta files são importantes para que o projeto de Unity 
localize suas partes. 


7.3 Build automatizado 


A Unity engine possui um sistema interno que permite o build 
automatizado, o Unity CloudBuild 
(https://unity3d.com/learn/tutorials/topics/cloud-build/introduction- 
unity-cloud-build). Infelizmente, outras engines náo possuem uma 
preocupacáo táo forte quanto os builds automatizados, e seus 
sistemas costumam ser mais precários. 


Para os casos que o build automatizado não é parte da engine, 
acredito que será menos dor de cabeca utilizar um sistema já 
existente. Em uma pesquisa rápida pelo Google, procurando por Cl 
e Games (usei os termos em inglés pela maior variedade de 
respostas), nos deparamos com diversas referéncias ao Jenkins 
(https: //jenkins.io/) e ao Travis Cl (https://travis-ci.org/). Tanto o 
Travis quanto o Jenkins sáo bem comuns e versáteis. 


DICA 


Livro de referência em Jenkins, de Fernando Boaglio, Jenkins: 
Automatize tudo sem complica des (2016). 





Além disso, existe o TeamCity (https://www.jetbrains.com/teamcity/), 
otimizado para CH. Para outros softwares, encontramos mais outras 
fontes, como os Go Cle o Snap Cl. Na maior parte dos casos que 
pesquisei sobre build automatizado em jogos, me deparei com 
Jenkins, pois é uma plataforma bastante simples de utilizar, 
implementar trabalhos (jobs) e tem uma comunidade bastante ativa. 


O mais importante é que seu código é buildado em uma única 
etapa. Dependendo do seu grau de proficiência em Cl, é possível 
buildar nas mais diversas plataformas em uma única etapa 
automatizada. 


Uma parte importante da automatização de processos é a 
segurança de uniformidade e a garantia de que todos os testes 
serão executados da mesma forma. Isso vale tanto para a 
automatização de testes unitários, que podem ser rodados antes da 
etapa de build, quanto para a etapa de testes funcionais. Para quem 
utiliza a Unity, sugerimos testes unitários com NUnit e NSubstitute, 
e testes funcionais e de integração com o Unity Test 
Tools(https://www.assetstore.unity3d.com/en/H!/content/13802) — 
que, apesar de atualizações raras, ainda é uma ferramenta 
poderosa. Faça seu build ser autotestado e rápido. 


Neste capítulo, aprendemos sobre por que devemos utilizar Cl, 
como e onde utilizá-la. Também vimos como fazer tudo isso para 
games, mas o mais importante é que aprendemos quanto podem 
ajudar um mercado que tipicamente possui muitos bugs. De posse 
destas informações, podemos começar a pensar em design e build 
do jogo. 


CAPÍTULO 8 
O mundo entre o design e o build 


No capítulo referente aos primeiros passos no Lean, mencionamos 
brevemente o que seriam design e build. Sendo assim, nosso 
objetivo agora é explicar a fundo o que sáo estes conceitos e como 
utilizá-los no Lean Game Development. 


De modo geral, o design é responsável por prever o que vai ser O 
software (desde a parte artística e visual até a parte de experiéncia 
da usuária). Já o build refere-se ao momento no qual se pensa de 
que modo obteremos o design idealizado, e o que é e náo é 
possível de se fazer. Á seguir, vamos contextualizar essas 
diferenças no desenvolvimento de um jogo. 


Uma frase muito importante para distinguir design e build é: "O 
design produz a receita e o build prepara a refei ão”. Trata-se da 


distincáo entre planejar e fazer. O design se preocupa com a 
utilidade e o build com as especificações técnicas e as 
ferramentas. 





8.1 Um pouco do design 


A formulacáo do design do jogo por si só já envolve uma série de 
iterações, e pode ser um momento de reflexão para verificar se vale 
a pena continuar o projeto. Entretanto, sua principal função não é 
essa. 


Uma parte importante associada ao design é procurar as 
informações, as necessidades e a utilidade do projeto. Muitas vezes, 
é necessário perguntar a pessoas desconhecidas o que pensam do 


projeto em questáo e/ou criar jogos de tabuleiro que tentem simular, 
da forma mais precisa possível, as mecánicas e features do jogo a 
ser desenvolvido, permitindo assim garantir que o jogo é viável e 
tem potencial. 


Um design eficiente permite um desperdício mínimo de recursos e 
tempo. Design é a etapa na qual os elementos do projeto seráo 
priorizados e, além disso, as especificações rígidas são custosas 
para serem modificadas. Por isso, tudo o que puder ser decidido em 
outra iteração deve ser deixado para alguma iteração seguinte. 
Lembre-se de que deixar para depois não significa não fazer, mas 
significa que não é interessante se estressar agora com algo que 
ainda não deve ser resolvido, não pode ser resolvido, que está 
bloqueado por qualquer razão etc. 


Para o sucesso do design, é necessário pensar em como será a 
ambientação do jogo, como serão as personagens, que features e 
mecânicas deverão conter no jogo, que tipo de experiência 
queremos que as usuárias tenham com ele, o enredo e seu 
gameplay. Pensando numa cena ao estilo Castlevania, na qual uma 
personagem esteja de costas tocando piano, será que vale a pena 
fazer uma animação supercompleta ou algo minimamente realista? 
É uma decisão importante do design, que pode afetar a fase de 
build. 


8.2 Um pouco do build 


E o build? Build é uma etapa em que se utilizam todas as questões 
definidas no design para poder começar o processo de 
desenvolvimento. Devemos lembrar de que, em jogos, desenvolver 
significa também a incorporação de artes e efeitos sonoros. Esses 
elementos foram decididos durante o design e não são algo com o 
que devemos nos preocupar neste momento. 


Se as soluções pensadas não forem boas, perceberemos nas 
próximas iterações, pois os conceitos devem ser desenvolvidos no 
período de Ideação - Hipóteses — Design. Isto é, durante o build, 
podemos discutir algumas especificações de estilo e de 
desenvolvimento. É importante que o desenvolvimento acompanhe 
o código e seja integrado continuamente, pois é um processo 
criativo que se modifica com o tempo, no qual os feedbacks são 
importantes. 


Por exemplo, conhecemos a história de um jogo que possui uma 
cena na qual a personagem vira de costas e começa a tocar piano. 
A artista se empolgou e animou toda a cena da personagem 
tocando piano, mas os seus dedos nunca são vistos. Isso teria sido 
facilmente evitado se tivesse havido as etapas de prototipação e 
entrega contínua. No build, podemos definir quais serão os testes 
unitários que faremos, como serão feitos os funcionais, observar se 
algum padrão de programação aparece e como todas essas coisas 
serão entregues, automatizadas, testadas e integradas. 


8.3 Muito bonito, mas como se faz? 


Antes de tudo, temos nosso MVGO (um jogo de tabuleiro), um 
momento que vemos se as mecânicas e features do jogo no geral 
serão interessantes, divertidas e coerentes. Criar um jogo de 
tabuleiro geralmente exige muita criatividade e permite que todas as 
equipes visualizem o que queremos ter como produto. 


O jogo de tabuleiro que concebemos consiste em um no qual o 
tabuleiro é dividido de forma tabular: a parte inferior do jogo é 
formada por espaços não interativos (solo) e espaços que podem 
gerar a morte da jogadora (buracos). O comportamento dos inimigos 
é gerado por um valor aleatório (resultado de um dado) a cada 
turno. 


A personagem principal pode se movimentar livremente de acordo 
com os dados, mas um pulo custa uma unidade de dado. Do mesmo 
modo que, no Mário, determinamos que matar os inimigos implica 
em cair em cima do inimigo, então, se a personagem para em cima 
do inimigo, ele morre. Inimigos somente podem se mover de -3 a 3 
posições na horizontal. Para ganhar o jogo, são suficientes 3 vidas. 


O jogo de tabuleiro é um grupo de ciclos completos, que podemos 
fazer de forma enxuta, sem grandes complicações artísticas. A 
figura a seguir é o nosso protótipo do MVGO; garantimos que foi 
divertido construí-lo e ele nos rendeu muitas horas de jogo. 


“elo deb 





Figura 8.1: Protótipo do jogo de tabuleiro 


Considerando que nosso modelo tem 8 protótipos que formam 4 
MVGs, e que sabemos que cada iteração corresponde a um 
protótipo, teremos, portanto, que fazer pelo menos 8 iterações. 


Temos as hipóteses iniciais, mas sabemos que teremos de idear 
para as iterações seguintes, gerando novas ideias. 


Na primeira etapa de design, definimos a narrativa do primeiro MVG, 
de forma que o PO possa orientar a visão do jogo e indicar como 
queremos que as mecânicas do protótipo1 se pareçam. As figuras a 
seguir representam as idealizações de como funcionam as 
mecânicas e algumas artes-conceito para os protótipos do MVG1. 





Figura 8.2: Sketch original da personagem — Artes de Diego Kim 
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Figura 8.3: Sketch original da mecânica de movimentação 


E 
calcada 


Figura 8.4: Sketch original da mecânica de pulo 


Figura 8.5: Sketch original da mecánica de queda 
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Figura 8.6: Spritesheet da personagem — Arte de Diego Kim 


E nosso build? Como seráo os testes? Quais seráo as ferramentas? 
Como serão feitas as animações? Os sprites? Quanto tempo 
projetamos para essa iteração? Como tudo será integrado? Como 
entregaremos? Quem serão os pares? Onde faremos o 
versionamento do código? O que temos ainda é válido? Funciona? 
Vale a pena migrar? São as perguntas que respondemos com as 
figuras adiante. 


Os testes são exemplificados nas tabelas do próximo capítulo. A 
primeira figura a seguir mostra as preferências de ferramentas para 
desenvolvimento de jogo: o padrão verde forte é o preferido, o verde 
fraco o menos preferido, e o vermelho, os excluídos. A segunda 
figura a seguir mostra nossas preferências por ferramentas de 
integração. Decidimos utilizar a ferramenta piskel para gerar os 
sprites e animar via Unity. 


A terceira figura a seguir representa nossa idealização de possíveis 
etapas de entrega contínua. Nosso versionamento de código foi feito 
via GitHub; não possuíamos código válido para este jogo, porém 
utilizamos um código experimental antigo. 


1 Monogame 3 
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Figura 8.7: Ferramentas de desenvolvimento de jogos 
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Figura 8.8: Ferramentas de integracáo 


Sequenciador de Entrega 


Cada uma das sequéncias de cores representa um processo de entrega 





Figura 8.9: Sequenciador de entrega contínua (CD) para o jogo 


SPRITES 


Sprites sáo artes 2D usadas para criar personagens e ambientes 
de jogos, geralmente, em 2D. A forma mais popular de sprite 
atualmente sáo as pixel arts. Um conjunto de sprites para gerar 
diferentes animações é chamado de sprite sheets. 


APE 


Figura 8.10: Exemplo de spritesheet. Fonte: 
https://www.codeandweb.com/texturepacker/tutorials/how-to-create-a-sprite-sheet 


Um bom editor de sprites é o Piskel. Ele permite gerar sprites 
pixel a pixel, com diversas cores e ferramentas 


(http://www.piskelapp.com/). 
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Figura 8.11: Editor de sprites Piskel 





Agora sabemos as diferenças fundamentais entre design e build. 
Vimos nossas expectativas para cada uma das etapas e um 
exemplo interessante de usabilidade dos conceitos. Com tudo 
definido, podemos passar para a parte que costuma ser mais 
prazerosa: codar e testar. 


CAPÍTULO 9 
Testar, codar, testar 


A etapa fundamental para um jogo é o código! Apesar do jogo ser 
um software artístico, ele ainda precisa ser codado e testado. 
Entretanto, qual seria a melhor forma de iniciar este processo? 


O game design já foi feito, mas como transformar o game design em 
um jogo com o mínimo de bugs possíveis? Aqui entram as técnicas 
de desenvolvimento de software, como o TDD e o XP (eXtreme 
Programming). Náo é preciso seguir literalmente as técnicas de 
desenvolvimento citadas e adaptações são sempre bem-vindas, 
portanto, é importante utilizá-las como guias no desenvolvimento. 
Uma das lições mais importantes para tirarmos delas é o fato que 
testar é muito importante, por isso precisamos de testes desde a 
primeira etapa, desde a primeira feature. 


Assim, quando pensamos no desenvolvimento, uma série de 
perguntas surgem, como: para a feature específica, como faremos 
nos casos de teste? Qual o teste mais simples possível? Qual será 
nosso passo a passo? E a automação de testes, como será feita”? 


Todas essas perguntas devem ser feitas e planejadas no build para 
que a etapa de codar e testar seja a melhor possível. Alguns dos 
tipos de testes são: 


e Teste unitário: teste de uma unidade, de uma classe ou de 
uma rotina, desenvolvido pela programadora. Um bom teste 
seria garantir que, ao pressionar o botão X, a personagem 
pulará. São os clássicos testes de assert em exemplos de TDD. 

e Teste de componente: é a execução de uma classe, pacote ou 
pequeno programa que envolve o trabalho de várias 
programadoras ou de uma equipe de programadoras. Um bom 
exemplo seria um teste no qual uma máquina de estados é 
testada em diversos aspectos. 


e Teste de integração: teste entre duas ou mais classes, 
pacotes, componentes ou sistemas. Começa quando existem 
duas classes diferentes. Um bom exemplo seria quando o Mário 
cai sobre um koppa, garantir que o koppa vai se tornar um 
casco e sair “rolando”. 

e Teste de regressão: testes de integração contínuos de forma a 
procurar defeitos, antes não encontrados, com versões 
diferentes. Uma espécie de teste de contrato, que procura 
garantir que um grande conjunto de features e suas integrações 
funcionarão independentemente da versão. 

e Teste de sistema (jogo): é a execução do software em sua 
configuração final. Testa todas as possíveis soluções e 
interações. Algo como um teste end-to-end, em que geramos 
um bot que permite testar todas as possíveis features do jogo 
(técnica muito usada para gerar gameplays). 


9.1 Casos de teste 


Vamos começar com um exemplo simples, que não é aplicado ao 
mercado de games, mas que a maior parte das programadoras já 
teve de enfrentar em algum momento. Imagine que sua equipe deve 
desenvolver uma feature para uma empresa que utiliza um sistema 
bancário. A feature em questão é a validação do número do cartão 
de crédito, de modo a garantir que o número inserido é válido. A 
tabela a seguir nos demonstra um caso. 


Tabela 9.1 Casos de testes para features 


Feature Testar a validade de um cartão de crédito 


Uma string representando o número do cartão de 
Entrada crédito, e dois números para representar o més e ano 
no qual que o cartão expira. 


Feature Testar a validade de um cartáo de crédito 


Testes 1. Checar se todos os bytes da string sáo dígitos. 


Saída 


2. Checar se os meses estáo entre 1 e 12. 
3. Checar se o ano é maior que o ano atual. 


4. Checar se os 4 primeiros dígitos do cartáo é de um 
emissor válido. 


5. Checar se o sistema é válido em um sistema 
externo. 


OK, ou erro com mensagem indicando que o cartáo é 
inválido. 


As estratégias de testes recomendadas para desenvolvedoras sáo: 


Testar cada requisito ou feature certificando-se de que todo o 
código esteja testado, garantindo a qualidade do código. Além 
disso, os testes devem ser estabelecidos na etapa de build, de 
modo que favoreçam o desenvolvimento, já que isso facilitará a 
visáo do que se deve fazer. 

Comece com testes de base, unidades fundamentais para o 
funcionamento do código, para, assim, avancar até testes mais 
detalhados e específico, aqueles que representam 
componentes e features mais complexos. 

Cada linha de código deve estar testada. É a única maneira de 
garantir a integridade contínua ao longo do desenvolvimento do 
jogo e também uma ótima forma de documentacáo. 

Liste todos seus erros no projeto para acompanhar seu 
desempenho e melhorar sua técnica. Uma forma de realizar um 
desenvolvimento pessoal. 

Escreva os testes antes de comecar a programar. Além de ser 
algo visto como uma boa prática de programacáo, esta técnica 
quase garante que náo se escreverá mais código do que o 
necessário. 


e Procure fazer testes limpos. Resumidamente consiste em 
manter o teste e o código compreensíveis e simples em um 
nível besta da simplicidade, o KISS. 

e Revise seu trabalho. 


KISS (Keep it Simple, Stupid) é um princípio geral que valoriza a 
simplicidade do projeto e defende que toda a complexidade 


desnecessária seja descartada 
(https://pt.wikipedia.org/wiki/Keep It Simple). 





9.2 Codar 


Codando arte de game 


Codar pode envolver muito mais que o código escrito para fazer um 
software funcionar. Nesse quesito, codar pode significar criar, pois 
grande parte das artes serão desenvolvidas neste momento e 
também serão testadas, mesmo que seja à sua maneira. Como as 
artes passam por um processo criativo que não pode ser guiado por 
testes, temos mais dificuldade para entender como aplicar os 
princípios do TDD às artes. 


Fora isso, como muitas vezes o processo de criação artística é algo 
muito subjetivo, pessoas diferentes vão responder de formas 
diferentes a estímulos diferentes. Uma solução para isso é focar nas 
menores unidades artísticas possíveis. 


Vamos ao exemplo da Jujubs: para testarmos seu código, não 
precisamos de nenhuma grande arte, somente um conjunto de 
blocos e outras formas geométricas que possam passar a sensação 
de que estamos jogando com uma personagem. Outro ponto 
importante que já foi mencionado por pessoas é que o processo 
criativo não deve ser interrompido. 


Concordamos que uma inspiração artística não deva ser 
interrompida, mas quantos são os jogos que sofreram bloqueios 
artísticos devido à falta de amadurecimento de ideias? Um exemplo 
é o FEZ. O ponto a ressaltar aqui é que nem todas as etapas da 
criação artística devem ser livres em todos os aspectos. 


Neste caso, já sabemos quem queremos atingir, pois isso ficou 
estabelecido com a definição de nossas personas. Além disso, 
devemos escolher nossas prioridades, e essa é uma ótima forma de 
permitir que nosso cérebro reflita mais sobre o que queremos e 
como poderemos fazer o que concebemos. 





FEZ 


Jogo indie desenvolvido por Phil Fish, no qual a personagem 
Gomez recebe o "fez", que revela a ele que seu mundo 2D é na 
verdade uma das quatro faces de um mundo 3D. O jogo 
apareceu no filme Indie Game: The Movie. 


a 


` / q A 





Figura 9.1: Poster do jogo FEZ. Fonte: https://en.wikipedia.org/wiki/Fez_(video_game) 





E quanto ao design artístico guiado por testes? Primeiro, devemos 
lembrar de que temos uma separacáo clara de prioridades no 
protótipo e, portanto, náo devemos nos preocupar com o que ainda 
náo fizemos ou com o que temos de fazer. Em uma primeira etapa, 
devemos simplesmente nos preocupar com a forma prototipada do 
que queremos. 


Como o primeiro protótipo costuma ser mais curto, quem sabe 
simplesmente fazer uma figura humanoide com cabelos compridos e 
uma roupa simples cobrindo o corpo? Náo precisamos nos ater a 
detalhes e nem pensar qual seria a melhor ou a pior forma, mas 
simplesmente nos permitir um bom ponto de partida. 


Deseja testar esse protótipo? Como arte é algo subjetivo, quem 
sabe testar pedindo feedbacks e explicando que se trata de um 
protótipo. Elencar os feedbacks mais parecidos e verificar se eles 
sáo coerentes com nossas prioridades: se eles náo forem, quem 
sabe utilizar um parking lot (explicado no Anexo A)? Aplicamos as 
mudanças necessárias e, a partir disso, teremos nosso protótipo 
harmonioso/elegante/artístico e testado. 


E os testes automatizados da nossa arte? Infelizmente, nossas 
redes neurais ainda não são capazes de realizar esse tipo de 


testes. Quem sabe em um futuro próximo o deep mind do 
Google venha a ser um primeiro passo. 





9.3 Codando software de game 


Temos nossos objetivos claros do que deve ser codado primeiro: o 
nosso protótipo1. Para tanto, desenvolvemos as tabelas a seguir 
como um guia de como todas as etapas deveriam ser feitas, pois na 
etapa de build, decidimos quais testes seriam realizados para cada 
uma das features que pensamos para o primeiro protótipo. 


Lembremos de que, apesar de já termos definido os próximos 
protótipos, eles podem ser quebrados em outros e reestruturados a 
partir do processo de feedback e ideação. Nossas features para o 
protótipo1 são caminhar, pular e cair. 


Tabela 9.2 


Feature 


Entrada 


Testes 


Saída 


Tabela 9.3 


Feature 


Entrada 


Desenvolvimento da feature de caminhar 


Personagem deve caminhar na direção do eixo x 
Entradas do teclado. 


1. Checar se uma key específica do teclado está 
sendo pressionada. 


2. Checar se as keys de direção (esquerda e direita) 
estão sendo pressionadas. 


3. Checar se, quando a key de direção para a 
esquerda é pressionada, a personagem se move para 
a esquerda. 


4. Checar se, quando a key de direção para a direita 
é pressionada, a personagem se move para a direita. 


5. Checar se outras keys, quando pressionadas, não 
movem a personagem (podemos em muitos casos 
excluir as keys ASWD). 


6. Checar se a personagem colide com os finais de 
cenário. 


Se a nova posição está de acordo com o previsto, o 
teste passa; caso contrário, falha. 


Desenvolvimento da feature de pular 


Personagem deve realizar um pulo 


Entradas do teclado. 


Feature 


Testes 


Saída 


Tabela 9.4 


Feature 


Entrada 


Testes 


Personagem deve realizar um pulo 


1. Checar se a barra de espaco está sendo 
pressionada para o pulo. 


2. Checar se, quando a tecla é pressionada, a 
personagem se move para cima em uma posicáo. 


3. Checar se a personagem se move de forma suave 
de baixo para cima (checar mais de dois pontos 
primeira parte do pulo). 


4. Checar se a personagem se move de forma suave 
de cima para baixo (pulo completo). 


5. Checar se, quando uma tecla de direcáo é 
pressionada, o pulo ocorre na direcáo x também. 


6. Checar se o pulo ocorre de forma a realizar uma 
parábola (5 pontos, pelo menos). 


Se a nova posicáo está de acordo com o previsto, o 
teste passa; caso contrário, falha. 


Desenvolvimento da feature de cair 


Personagem deve cair quando houver buracos no 
cenário 


Colisáo da personagem com o cenário. 


1. Checar se a personagem colide com partes do 
cháo. 


2. Checar se a personagem colide com blocos aéreos 
no cenário. 


3. Checar se a personagem cai quando houver um 
buraco no cháo. 


Personagem deve cair quando houver buracos no 


Feature o 
cenário 


4. Checar se a personagem cai de forma a realizar 
um lançamento horizontal afetado pela gravidade a 
partir do chão. 


5. Checar se a personagem cai de forma a realizar 
um lançamento horizontal afetado pela gravidade a 
partir de um bloco aéreo. 


Se a nova posição ou o novo estado estão de acordo 


Saída E 
com o previsto, o teste passa; caso contrário, falha. 


Os exemplos apresentados anteriormente corresponde aos 


testes criados para o primeiro MVG do jogo Super Jujubs. 





Cada programadora pode idealizar de forma diferente como estes 
testes serão realizados, mas o importante é manter a codificação 
deles simples e a resolução ainda mais simples. Caso algum passo 
fique vago ou meio obscuro, conceber e executar um teste 
intermediário pode ser uma boa solução. Fora isso, qualquer 
modificação mais profunda, como refatoração e extração de classes, 
pode se tornar muito menos trabalhosa com a correção dos erros 
através dos testes. 


No desenvolvimento de softwares, é muito comum fazer atualização 
de versão, assim como fazer updates em jogo. Identificar testes 
quebrados e diferenças entre esperado e encontrado pode ser uma 
ótima forma de otimizar o tempo de atualização de código, sem 
precisar rever toda a lógica. Além disso, fica muito mais simples 
entender o que o código deve fazer quando os testes documentam o 
que deve acontecer. A sugestão é sempre começar pelo mais 
simples e fundamental, para sempre garantir que o mínimo 
planejado está acontecendo. 


9.4 Automatizacáo de testes 


Testes unitários desenvolvidos pela programadora sáo uma ótima 
fonte para iniciar a automação, pois eles são fundamentais para 
verificar se as features estão funcionando de forma adequada. 
Portanto, é importante automatizar o processo no qual isso é feito. O 
test runner é responsável por rodar todos os testes e verificar o 
resultado, e os testes devem ser escritos de forma que os 
resultados de comportamento sejam os esperados. 


Alguns componentes da automatização de testes são descritos a 
seguir: 


e Gerenciador de testes: gerencia o funcionamento dos testes 
do programa. Outra função é manter registro dos dados de 
teste e resultados esperados. 

e Gerador de dados de teste: gera os dados que devem ser 
testados pelo programa. Pode ser por padrões pré-definidos ou 
dados aleatórios necessários para etapas específicas do jogo. 

e Gerador de dados esperados: sua função principal é gerar 
todos os possíveis dados para um teste automatizado, como o 
end-to-end. 

e Comparador de resultados: sua principal função é comparar 
resultados novos com antigos. 

e Gerador de relatórios: gera os relatórios dos resultados de 
testes. 

e Analisador dinâmico: serve para perceber e contar chamadas 
de cada função chamada pelo código. 

e Simulador: simula as interações de usuário com diferentes 
tipos de sistemas; algo como testar diferentes plataformas. 


TEST RUNNER 


É uma ferramenta que permite rodar uma sequéncia de testes 
de todos os tipos com base em linha de comando. No caso da 
Unity, o test runner ainda permite uma integracáo entre teste e 
visual, permitindo á programadora verificar o que está 
acontecendo. No capítulo Desenvolvimento Guiado a Testes, há 
vídeos sobre como usar o Unity Test Tools que inclui o test 
runner. As figuras a seguir mostram como é o test runner visual 
e um exemplo de comandos para o seu funcionamento via linha 
de comando. 


Editor Tests 


Run All | Run Selected | Rerun Failed "2. Y 1 


Y  MyUnityProject 
Y v EditorTestsExample 
EditorTest 


EditorTest [0.008s] 











Figura 9.2: Test Runner Visual integrado a UNITY. Fonte: 
https://docs.unity3d.com/Manual/testing-editortestsrunner.html 


>Unity.exe -runEditorTests 

-projectPath PATH TO YOUR PROJECT 
-editorTestsResultFile C:1templresults.xml 
-editorTestsFilter Player 


Figura 9.3: Test Runner a partir da linha de comando. Fonte: 
https://docs.unity3d.com/Manual/testing-editortestsrunner.html 





A ideia aqui era definir o que fazer antes de codar, definindo os 
testes e as políticas de desenvolvimento. Além disso, vimos 
ferramentas ótimas para utilizarmos boas práticas de testes. 
Infelizmente, agora, precisamos focar em pegar o que já integramos 
e buildamos com nossos conceitos de métricas. 


CAPÍTULO 10 
Medir e analisar 


Muito falamos de como iterar e que, para isso, precisaríamos de 
formas de medir e analisar nossos resultados. Portanto, a primeira 
etapa é conseguir medir os resultados que nossa iteração obteve, e 
a melhor maneira de fazer isso é via feedbacks, em todos os 
âmbitos (time, usuários, mercado, clientes, mídia). 


Mas o que são nossos feedbacks e como medi-los? Além disso, 
como devemos analisá-los? E o que devemos fazer com nossas 
análises? Nosso objetivo é, na verdade, maximizar o aprendizado 
através das iterações e, portanto, desenvolver com mais qualidade e 
segurança a cada iteração. 


10.1 Feedbacks 


Feedbacks podem ser de vários tipos, mas os principais deles, 
especialmente em jogos, são aqueles sobre reações a produtos, ou 
sobre avaliações de desempenho de uma pessoa em uma task. 
Eles possuem como objetivo melhorar o produto ou o desempenho 
das pessoas. 


Feedbacks podem ser dados de maneira contínua, ou quando 
ocorrerem situações relevantes. É importante manter a cultura de 
feedbacks, pois seu objetivo é melhorar o desempenho pessoal ou 
qualidade do produto. Para isso, é preciso sempre estar em busca 
de feedbacks, seja com clientes e usuárias, seja com colegas de 
trabalho. 


Uma das maneiras de receber feedback de produtos é por meio de 
contas no Twitter. Um costume bastante desenvolvido na 
comunidade dev de jogos é possuir contas ativas, na qual as 


pessoas postam fotos, fazem comentários sobre seus novos 
lancamentos e, ao mesmo tempo, recebem feedback das 
clientes/usuárias. Outra maneira é incentivar toda a equipe a 
participar ativamente da coleta de feedbacks ao longo do 
desenvolvimento do jogo, sejam feedbacks da PO, das analistas de 
negócio e de marketing, ou de outras desenvolvedoras. 


Quanto a membros de equipe, é importante manter os feedbacks 
educados e sinceros. Tentar não inserir questões pessoais e manter 
o bom senso. Quando levados a sério, feedbacks podem permitir 
uma melhora de performance e corrigir pequenos defeitos, que 
todos temos. 


10.2 Mais sobre feedbacks 


Os tópicos a seguir sobre feedback foram retirados e re- 
elaborados do blog de Felipe Morais 


(https://medium.com/(Dfelipedemoraes). Quando li estes posts, 
achei muito interessante trazê-los como referência aqui. 





O que é um feedback? 


O feedback é uma ferramenta muito importante para entender como 
as pessoas a sua volta lhe percebem, quais comportamentos você 
pode melhorar, quais você deve continuar tendo e até intensificar. 


Feedback é a sugestão para reforçar ou melhorar um 


determinado ponto. 





O bom feedback costuma ser aquele que se baseia em 3 pontos 
principais: os dados observados sobre um fato, a história que 


construiu sobre ele e o raciocínio que fez vocé chegar a conclusáo. 
Vamos a um exemplo para deixar as coisas mais claras: 


FELIPE DIZ: Na atualização que você deu na reunião hoje, achei 
que você não foi clara no que falou. Pareceu que você estava 
dispersa. 


Julia diz: Obrigada, Felipe. Não tinha percebido isso, vou ser 
mais cuidadosa. 





Como dar feedback 


Existem alguns pontos que são importantes cuidar antes de dar um 
feedback. A seguir, eles são apresentados com uma breve 
descrição. 


e Começar a conversa: procure um ambiente de conversa mais 
tranquila, por exemplo, chamando para um café. Evite tensões 
desnecessárias. 

e Ambiente ideal: é importante dar o feedback a sós. Mais 
pessoas que o necessário na sala sempre pode gerar tensão 
entre elas. 

e Definir os objetivos da conversa: deixe claro o porqué desta 
conversa e como você crê que ela pode ajudar a pessoa. 

e O feedback: é sempre bom lembrar da situação que gerou o 
feedback e explicar a conclusão que você tirou do momento. 
Este é o momento para falar o que precisa, e lembre-se de 
sempre dizer como o feedback pode ajudar a pessoa. 

e Validar o recebimento: valide se a pessoa concorda ou não, e 
abra espaço para dúvidas. Não há necessidade das pessoas 
concordarem com o que foi dito. 

e Evitar climas ruins: é o momento de ter empatia e sentir como 
a pessoa reagiu. Caso ela tenha reagido de forma negativa, é 
sempre bom lembrar de que o objetivo era ajudar e que de 
forma alguma você tentou ser agressivo. 


e Intervalo entre o momento e o feedback: é importante 
lembrar de que quanto mais distante o feedback for do 
momento, menor a chance de a pessoa lembrar do ocorrido e 
menor o impacto do feedback. 


Mais informacóes sobre feedbacks podem ser encontradas no 


blog mencionado no início da seção. 





10.3 Outras formas de medir 


Uma forma bastante comum é receber feedback de empresas 
especializadas em jogos, permitindo que eles joguem um demo, alfa 
ou beta. Essas empresas, além de terem impacto publicitário 
positivo, podem trazer ótimas recomendações e feedbacks. E o que 
fazer com essas informações que é o diferencial. 


É importante lembrar de que, durante todas as etapas do 
desenvolvimento, é necessário medir como anda o produto. 
Portanto, precisamos buscar formas de receber informações sobre a 
qualidade, lembrando de que a visão de devs sobre como é o jogo 
costuma ser bastante enviesada. 


e Procurar ter empatia: muitas vezes pode haver conflitos entre 
a visão da PO e a da equipe. Nestes momentos, é necessário 
tentar entender por que cada uma das partes possui 
divergências em suas visões. 

e Procurar coletar opiniões e ideias dos membros da equipe: 
apesar de desenvolvedores, os membros da equipe também 
costumam jogar jogos. Seus insights e sugestões podem ser 
muito positivos para o desenvolvimento do jogo. 

e Fazer sessões de testes de demos: muitas pessoas ficam 
esperando horas na fila para testar jogos demos. Uma boa 


forma de medir é lancando demos em eventos e analisando as 
reações das pessoas ao jogo, além de coletar feedbacks. 

e Validar hipóteses: veremos mais sobre a seguir. 

e Analytics: existem várias formas de coleta de dados. 
Atualmente, utilizar esses dados para melhorar a experiência de 
jogo é uma ótima maneira de medir. Neste caso, tenho dois 
exemplos: 

o Call of Duty - Black O ps 2 foi o jogo que mais vi 
modificarem o desempenho de armas, e criarem armas 
novas com balanço melhor de propriedades. Exemplo disso 
é diminuírem o dano da arma Fal, e criarem uma arma 
nova na DLC (conteúdos extras para download). 

o Outro jogo que me vem a mente é o Starlit, da Rockhead. É 
um ótimo exemplo, pois conseguiu prender meu filho por 
horas seguidas. Neste jogo, eles, a equipe da Rockhead, 
observaram o desempenho médio dos jogadores em certas 
regiões do jogo. Quando era muito fácil, eles dificultavam; 
quando era muito difícil, eles facilitavam ou melhoravam a 
experiência de jogo. Na minha opinião, uma das melhores 
formas de medir. 


ANALYTICS 


Analytics é a descoberta, interpretação e comunicação de 
padrões significativos em dados. Pode ser usado para 
descrever, predizer e melhorar o desempenho do negócio/jogo. 
Paraga Jogos é uma ferramenta poderosa para compreender o 
comportamento das jogadoras, provendo insights valiosos sobre 
elas e o jogo. Alguns sites com possibilidades de uso de 
analytics estão descritos a seguir: 


e Game Analytics: https://github.com/GameAnalytics 
e Unity: 
https: //www.assetstore.unity3d.com/en/H/content/6755 


ARPPU 


$0.34 +214% $21 4 + 9.18% 


Figura 10.1: Exemplo de resultados de Game Analytics 





10.4 Medindo através de hipóteses 


Muitos capítulos atrás, falamos de hipóteses e que elas nos 
ajudariam a medir e testar nossos MVGs/protótipos. Entretanto, até 
agora, náo usamos nossas hipóteses para nos retornar resultados. 
Resultados váo muito além de simples dados, pois dados podem ser 
coletados de forma parcial; pode haver intencionalidade na procura 
de bons dados, evitando dados negativos, o que afetará seu 
resultado. 


Precisamos de formas de medir nossas hipóteses que nos retornem 
informações que nos gerem conhecimento, sejam para o bem ou 
para o mal. Essas informações e resultados possuem o grande valor 
de nos proporcionar futuros insights. 


Sabemos que tornamos nossas ideias e insights em hipóteses para 
serem avaliados no futuro. Essas nossas hipóteses tiveram como 
objetivo este momento em que medimos e analisamos, além de 
ajudar a manter a visão do jogo. 


Elas não deixam de ser uma etapa quase científica para avaliação 
de resultados, já que são elas que serão testadas e somente 
poderão ser modificadas na próxima iteração, que ocorrerá após a 
análise e o aprendizado. Através de toda a coleta de informações e 
feedbacks que fizemos, podemos colocar as hipóteses à prova, sem 
selecionar dados e mantendo um julgamento o mais imparcial 
possível. 


Acho que é um momento importante para lembrar de que o objetivo 
das empresas de jogos não é ganhar dinheiro em si, mas 
proporcionar um ótimo entretenimento. Portanto, se suas hipóteses 
se baseiam em métricas financeiras, há uma grande chance de seu 
jogo falhar ou não ser inovador e divertido. 


Uma consequência da avaliação de hipóteses é conhecer os 
clientes e saber melhor qual é o possível impacto do jogo no 
mercado. Validar hipóteses é mexer com riscos, pois é muito mais 
fácil desenvolver pensando que tudo está certo do que desenvolver 


observando as falhas. Nosso modelo de hipótese até agora é o 
descrito a seguir: 


Nós acreditamos que: 


construindo a funcionalidade [nome da funcionalidade/protótipo] 


para o público [público-alvo proposto] 
atingiremos /resultados esperados] 


Saberemos que fomos bem-sucedidos quando tivermos fo sinal 
do mercado esperado] 





Bom, temos o público que queremos atingir, o resultado que 
queremos obter com o MVG ou com o protótipo, e a métrica que 
definimos como sinal esperado. Com essas informações, podemos 
parar para pensar se o nosso público-alvo deu o sinal esperado de 
nosso resultado por meio de feedbacks e analytics, por exemplo. 


Fora isso, dados de vendas e downloads podem contribuir. Porém, 
eles costumam ser mais nebulosos quanto ao público-alvo, já que 
muitas usuárias náo costumam deixar seus dados pessoais públicos 
ou utilizam dados falsos. 


Comentários na página do jogo ou nas contas de Twitter também 
podem ser uma ferramenta potente na validacáo de hipóteses. Mas 
e com essas medidas de sinal, sejam elas positivas, negativas, 
complexas ou simples, como podemos realizar a análise sobre 
nossas métricas e hipóteses”? 


10.5 Analisar 


Na hora de analisar, precisamos manter a seriedade e fazê-lo de 
forma impessoal e imparcial. Quanto mais informações e resultados 


estiverem disponíveis a partir da validacáo de métrica, mais 
importante e relevante será a análise. Ao mesmo tempo que a 
importáncia da análise aumenta com a qualidade e quantidade dos 
dados, a complexidade e o benefício também aumentam. 


Assim, quando formos analisar, devemos separar tudo o que 
buscamos e tudo o que temos, de forma que possamos classificar 
os tipos de feedbacks, dados e métricas como desenvolvemos 
nossas hipóteses, e manter a possibilidade de desenvolver estes 
pontos futuramente. As medidas de sinal resultantes das métricas, 
dos MVGs/protótipos, das features e das mecánicas permitem-nos 
identificar pontos de melhora. 


Após realizar essa etapa, podemos separar por ordem de releváncia 
ou impacto no desenvolvimento do jogo. Isso nos permite analisar o 
quanto e onde se precisa melhorar o produto/jogo. Importante 
também é lembrar de que muitos dos feedbacks sáo desconexos 
com as necessidades do jogo ou da equipe. Estes muitas vezes 
podem ser úteis, mas náo para o momento, assim vale deixá-los em 
parking lot (exemplificado no Anexo A) para serem usados depois. 


Durante a análise, é importante comparar também com as histórias 
e as personas geradas anteriormente, além de ter bem claro quais 
são as informações que queremos extrair de cada grupo de análise. 
Nossas métricas de sinal de hipóteses nos permitem verificar se o 
MVG/protótipo, a feature ou a mecânica estão adequadas, o que 
nos permite uma melhora para a próxima etapa, gerando uma 
melhora contínua. 


Exemplo sobre alcance do público feminino 


Vamos tomar o exemplo do capítulo Como gerar hipóteses?: 


"Nós acreditamos que, ao construir uma personagem feminina 
forte, náo estereotipada e com funcionalidades interessantes, 


poderemos atingir o público feminino, que por isso se empolgará 
com nosso jogo. Sabemos que fomos bem-sucedidas quando 
muitas meninas estiverem comentando no nosso feed". 





Essa hipótese está muito além de mecánicas e de features. Ela nos 
traz conceitos estéticos do jogo e um público geralmente deixado de 
lado, especialmente em jogos japoneses. Será que uma boa 
maneira de obter sucesso é divulgando a personagem e o jogo de 
forma paralela? Podemos verificar isso quando o jogo recém- 
lançado não possui muitos downloads de mulheres, mas, depois de 
algumas palestras, vídeos e tweets sobre o assunto, conseguimos 
uma legiáo de fás. 


Seria uma métrica adequada se fosse nossa intencáo com a 
hipótese, porém nós procuramos ouvir feedbacks diretos e gerar 
discussões. Se nossos feedbacks e discussões não aparecerem nas 
métricas obtidas, podemos ter de repensar o que conseguimos com 
a hipótese, como: 


e Nossa personagem era cativante para o público feminino, mas 
não o suficiente para permitir manifestações. 

e Não estamos disponíveis para receber feedbacks. 

e Houve uma falha de comunicação de nossa intenção. 

e Não alcançamos nosso público. 

e O tipo de jogo não era adequado ao nosso público (creio eu que 
todas as categorias de jogos podem ser adaptáveis a todos os 
públicos, por exemplo, crianças jogando jogos de terror 
pensados para suas idades). 

e O público adorou e o jogo é um sucesso! — Nunca acontece. 


Devemos analisar todos os feedbacks com seriedade, sejam 
eles representantes de 2 ou 100% deles. Porém, devemos 


colocar os mais comuns e os mais relevantes do ponto de vista 
da equipe como prioritários e, a medida que possível, procurar 
analisar os outros feedbacks que ficaram de fora. 





Exemplo sobre funcionalidades básicas 


"Nós acreditamos que construindo as funcionalidades de 
caminhar, pular e cair para o público de jogadoras, teremos 
como resultado um jogo com as mecánicas básicas fortes. 


Sabemos que fomos bem-sucedidas quando tivermos feedbacks 
positivos dos testes manuais e de terceiros, através de nossa 
demo". 





Essa é uma hipótese um pouco traicoeira, pois sabemos que sáo 
vários os jogos que se baseiam nestas mecánicas, e estes fazem 
muito sucesso em casos inesperados. Claro que os testers do jogo 
váo focar nas funcionalidades do ponto de vista técnico, entáo, por 
mais que se divirtam, o objetivo deles é ver se a "coisa" funciona. É 
uma informacáo relevante, pois se do ponto de vista dos testers, o 
jogo não estiver funcionando, deveremos tomar atitudes em relação 
a isso. 


Agora imagine dividir uma demo do jogo com pessoas aleatórias. 
Será que isso nos garante mais benefícios? Uma forma muito boa é 
enviar demos para youtubers fazerem reviews, mesmo que as 
demos tenham outros nomes. Escolha uma youtuber séria e ela 
revisará o jogo do ponto de vista de entretenimento e qualidade. 
Com estas situações, podemos sair com as seguintes análises: 


e As funcionalidades do jogo estão ruins e devem ser corrigidas. 
e A jogabilidade do jogo está ruim e o projeto deve ser 
repensado. 


e As funcionalidades estáo OK, mas o jogo náo é divertido. 
e O jogo é divertido, mas muito difícil de jogar. 
e A crítica foi ótima! 


Pensando assim, temos um conjunto de possíveis sinais sobre 
nossas hipóteses, e isso nos permite avançar para a próxima etapa, 
com medidas claras como feedbacks das mecânicas e das features 
do jogo, e analytics do desempenho das jogadoras ao longo das 
diferentes seções dele. Essas medidas nos permitiram analisar 
pontos fortes e fracos das funcionalidades a serem validadas pelas 
hipóteses e nos permitem pensar problemas, soluções e pontos de 
ação. Pensando em pontos de ação, podemos passar para a 
próxima etapa: as ideações sobre as ações a serem tomadas. 


CAPÍTULO 11 
Gerar ideias para iterar 


Antes de iterar, novamente é preciso ter ideias sobre o que é 
necessário melhorar para a próxima etapa e quais feedbacks podem 
ser usados para melhorar o jogo de forma geral. Após a etapa de 
medição e análise, precisamos colocar em uso todas as 
informações geradas, como os itens de ação. Esta etapa chama 
ideação, e é necessária para que possamos gerar novas hipóteses, 
repensar o design e os futuros builds. 


11.1 Itens de ação 


É importante que possuam um título, que seja bastante explicativo. 
Para uma breve explicação do que se trata e uma forma de 
contextualização, é necessária a presença de uma breve 
descrição. Além disso, é preciso ter uma apresentação de o que 
gerou o item de forma a apresentar a funcionalidade envolvida, a 
hipóteses base e o sinal identificado. Para concluir o item de ação, é 
interessante uma breve descrição da análise feita para sua criação 
— possivelmente designar uma responsável. 


Durante o processo de geração de ideias, pode ser útil retomar o 
conceito de Inception. Porém, desta vez, ela pode ser mais curta e 
focada, pois já temos os MVPs e, neste momento, a ideação serve 
para melhorar os conceitos dos MVPs, assim como gerar novas 
hipóteses e aperfeiçoar todos os conceitos de forma geral. 


O processo de ideação consiste em um brainstorming sobre os 
resultados anteriores e a geração de proposta de adaptações para 
os MVPs, sem perder o foco e a visão. É importante manter o 
julgamento imparcial neste momento. É a hora para se pensar "fora 


da caixa", podendo se aproveitar de técnicas que estimulem a 
criatividade, pois é uma das melhores formas de encontrar soluções 
para os problemas identificados nas etapas de medição e análise. 
Durante essa etapa, é recomendado ter os mais diversos perfis de 
pessoas, pois somente assim se conseguirá uma variedade 
adequada de ideias. 


Para organizar as sugestões, é legal usar o cardápio de ideias, que 
é uma síntese das ideias geradas até então, com o objetivo de 
ordenar os insights e torná-los visíveis e compreensíveis para todos. 
Uma boa forma de lidar com o problema é a Sketching Session, que 
ajuda com a definição do problema e com a proposta de melhoria 
para as funcionalidades. 


SKETCHING SESSION 


O [jogo/feature] é [o que se propõe] 


Para que [jogadores/usuários] possam [objetivo dos 
usuários] 


Observamos que [atual problema/limitação do sistema atual], 
o que faz com que [motivo de ser um problema] 


Como podemos [o que resolver] para que [qual benefício de 
resolver]? 





11.2 Exemplo de Sketching Session 


No capítulo anterior, utilizamos a seguinte hipótese para gerar 
métricas: 


"Nós acreditamos que construindo as funcionalidades de 
caminhar, pular e cair para o público de jogadores, teremos 
como resultado um jogo com as mecánicas básicas fortes. 


Sabemos que fomos bem-sucedidas quando tivermos feedbacks 
positivos dos testes manuais e de terceiros, através de nossa 
demo". 





Descrevemos uma série de possíveis análises, mas vamos nos 
restringir a duas para nossa Sketching Session: 


e As funcionalidades estão OK, mas o jogo não é divertido. 
e O jogo é divertido, mas muito difícil de jogar. 


Primeira análise 


As funcionalidades estão OK, mas o jogo não é divertido. 


O jogo é simples e focado em movimentação, exigindo cuidado em 
relação ao posicionamento, para que as jogadoras possam ter 
novas experiências em jogos de plataforma 2D. 


Aprendemos conforme os feedbacks que atualmente a jogabilidade 
e as mecânicas funcionam bem, mas que o jogo não é divertido, o 
que faz com que as jogadoras não se interessem pelo jogo e não o 
divulguem. Como podemos tornar a experiência mais divertida para 
que elas se divirtam e divulguem nosso jogo? 


ITEM DE AÇÃO 
Título: melhorar a experiência de jogo. 


Descrição: o jogo está com as funcionalidades OK, porém não é 
uma experiência de jogo divertida, sendo necessário idear sobre 
soluções. 


Contexto: com base nos aprendizados gerados via feedbacks 
de testes, o jogo não é interessante de jogar, apesar de 
funcionar muito bem. 


Análise: os testes das demos nos mostraram que, apesar da 
jogabilidade ser boa, é necessário melhorar a experiência de 
jogo, adicionando elementos que possibilitem mais diversão. 





Primeira ideação 


Aqui nosso objetivo é idear de forma a tornar o jogo mais divertido. 
Lendo um item de ação, podemos ter mais detalhes sobre o que 
aconteceu, mas vamos supor que o jogo não impôs nenhuma 
dificuldade. Assim, algumas das possíveis ideias giram em torno de 
incluir elementos novos nele. Algumas sugestões podem ser 
inimigos, objetos colecionáveis, intempéries, poderes ou qualquer 
outra ideia. 


Segunda análise 


O jogo é divertido, mas muito difícil de jogar. 


O jogo é uma plataforma 2D que traz novas experiências de 
jogabilidade. Ele tem como objetivo permitir que as jogadoras 
possam experimentar a diversão de uma plataforma, mas com um 
toque extra de genialidade. 


Observamos que o jogo está com mecánicas desajustadas ao 
ambiente do cenário, o que faz com que a jogadora náo consiga 
superar os obstáculos. Como podemos resolver a dificuldade de 
jogo para que ele se torne efetivamente jogável? 


ITEM DE AÇÃO 


Título: melhorar as mecânicas de movimentação. 


Descrição: é necessário tornar as mecânicas de jogo mais reais 
ou melhorá-las a ponto de tornar a experiência de jogo melhor. 


Contexto: com base nos aprendizados gerados via feedbacks, 
percebemos que, apesar da diversão, as jogadoras tiveram 
muitas dificuldades em superar obstáculos e se acostumar com 
as mecânicas. Análise: tornar as mecânicas de jogo melhor 
permitirá um maior aproveitamento de um contexto global do 
jogo, possibilitando que a experiência de jogabilidade e de 
narrativa se complementem de forma ótima. 





Segunda ideação 


Nossa ideação neste momento é identificar qual é a dificuldade do 
jogo e propor soluções. As dificuldades podem ser features mal 
implementadas, pulo irregular, falta de previsibilidade nos 
movimentos e muito mais. 


Vamos supor que o pulo é irregular, e isso dificulta saltar de uma 
plataforma para a outra, além de dificultar a eliminação de inimigos. 
Algumas sugestões podem ser repensar o pulo, verificar se a 
implementação consegue atingir os objetivos desejados, verificar se 
o design do pulo está de acordo com o design do level, verificar se o 
level está de acordo com as diferentes métricas do jogo, e muito 
mais. 


11.3 Repensar as limitações do desenvolvimento 
de jogos 


De modo geral, já verificamos várias limitações nas primeiras etapas 
do desenvolvimento do jogo, porém, muitas vezes, é necessário 
repensar quais são nossas limitações. Algumas dessas limitações 
estão a seguir: 


e Qual plataforma é mais importante agora? PC? PS4? Xbox 
One? Android? ¡OS? Aqui vale pensar qual delas estamos 
implementando, qual é mais fácil, que dificuldades a atual 
plataforma nos traz e outras dificuldades que possam aparecer. 

e Devemos evitar algo? Que tipo de jogador buscamos? Por 
exemplo, evitar muitos botões no caso de crianças pequenas, 
ou comandos simples caso seja mobile. Nosso MVP está 
preparado para abranger todos as possíveis jogadoras, ou 
devemos focar em um tipo só? 

e Como se darão os inputs e outputs? Já estamos preparados 
para usar joysticks, mouses e oculus-rift, ou somente podemos 
utilizar teclados? 

e As mecânicas são facilmente ajustáveis? Elas foram 
corretamente implementadas e são facilmente melhoradas caso 
seja preciso nos próximos MVPs? 

e Conseguimos melhorar os scripts sem quebrar a sensação de 
jogo? O código precisa ser refatorável e de preferência pouco 
acoplado, para que futuras mudanças não quebrem o código e 
a sensação de jogo. 


É neste ponto que estamos fechando um ciclo do desenvolvimento 
lean. É o momento em que vamos repensar nossas ideias, repensar 
hipóteses, iterar para corrigir o design e melhorar o build. Aqui, 
chegamos ao ponto no qual realmente podemos dizer que geramos 
aprendizado, pois propusemos soluções para os problemas 
encontrados, compartilhamos estes problemas e as suas soluções 
com o coletivo, e planejamos os próximos momentos. 


Agora falta somente a revisáo de hipóteses, revisáo do design, 
elaboração do build, e assim por diante, até que tenhamos iterações 
suficientes para encerrar nosso jogo. 


CAPÍTULO 12 
Mais sobre games 


Como diferenciar e classificar tudo o que costumamos chamar de 
games? O que realmente é essa classe de jogos digitais? 


São centenas de nomes que aparecem quando falamos dessa 
classe, como games, serious games, gamificação, adver-games e 
muitos outros. Uma forma bem simples de ver essas diferenças, na 
nossa opinião, é a tabela a seguir. 


Tabela 12.1 Diferenças entre coisas chamadas de jogos. X 
representa um requisito 


Game Elementos Mundo 


thinking de jogo virtual Samep'ay 
Playful X 
games 
Gamificação X X 
Adver- xX X 
games 
Simulacáo X X X 
Serious X X X X 
game 


Game X X X X 


A figura a seguir é uma classificacáo das diferencas entre os tipos 
de games e o que cada um se caracteriza, segundo Andrzejem 
Game Thinking (2015). 
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Figura 12.1: Separacóes dos tipos de jogos. Fonte: Marczewski (2015) 


Uma breve explicacáo de cada uma das categorias mostradas 
anteriormente: 


e Playful games: é algo que gira em torno de funcionamento e 
pensamento de games, mas não possui elementos de games 
fortemente atribuídos. Acaba que a interface lembra a de um 
game. 

e Gamificação: a ideia de gamificação gira em torno do conceito 
de tornar algo em uma coisa que passe a sensação de um jogo. 
Consiste em pegar uma ideia, transformá-la em uma ideia de 
algo jogável e introduzir elementos de jogos. 

e Serious games: jogos completos criados para motivos 
diferentes de puro entretenimento. 

e Games para aprendizado/ensino: jogos criados com o intuito 
de ajudar no aprendizado ou ensinar algo específico, jogando 
um jogo real. 

e Jogos significativos (propósito superior): tem o propósito de 
passar uma mensagem significativa à jogadora, como ensinar 


algum aspecto de conflito, a realidade de alguns grupos e muito 
mais. 

e Jogos propositais: são jogos que devolvem algum tipo de 
resultado real. É um grupo que pode abranger jogos 
significativos, games de aprendizado e serious games. 

e Simulação: uma representação virtual de algum aspecto real. 
Não necessariamente exige gameplay e geralmente tem algum 
propósito, muitas vezes propósitos militares. 

e Games: difícil definir o conceito, mas como vimos que a classe 
é ampla, vamos lembrar de que jogos de entretenimento podem 


pertencer a várias categorias, inclusive as mencionadas 
anteriormente. Muitos chamam os jogos de entretenimento e 
arte puros como play games, que pode causar confusão com 
playful games. São uma forma de arte, e muitas vezes 
chamados de filmes ou narrativas digitalmente interativos. 


Neste livro, vimos como usar diversas técnicas como utilização de 
Inceptions, MVPs (MVG e protótipos), análise métricas, TDD, 
integração contínua, planejamento de design e build para o 
desenvolvimento de jogos de uma forma que não exista 
necessidade de reinventar a roda toda vez que se for desenvolver 
um jogo, e de forma que os objetivos e visão do que se deve 
entregar estejam bem claros. 


Essas técnicas foram pensadas especialmente para jogos digitais 
com objetivo de entretenimento, mas podem ser aplicadas a 
qualquer tipo de software que possua Game Thinking. Assim, na 
hora de desenvolver seu próximo jogo, pense em quanto ele pode 
contribuir para a comunidade mais do que como fazê-lo. 


CAPÍTULO 13 
AnexoA Técnicas e ferramentas lean e ágil 


Este anexo tem como objetivo apresentar algumas técnicas que 
podem melhorar as dinámicas lean e ágeis de equipes. Primeiro 
vamos rever soluções para stand-ups. 


Stand-up Wall 


Sabemos que, em 90% dos casos, uma stand-up de 15 minutos 
acaba levando muito mais tempo que o necessário, muitas vezes 
interrompidas por situações inesperadas e conversas paralelas. 
Nossa solução propõe que a equipe encontre uma plataforma 
online, ou um board, em que cada par coloca quais são os cards 
que estão fazendo, os bloqueios, as soluções e possíveis ações. 


Depois em uma reunião curta (de preferência, antes do almoço), a 
equipe percorre cada um dos itens, explicando o que está 
bloqueando cada par, se há ou não possíveis soluções. Após isso, a 
equipe decide ações a serem tomadas, definindo quem pode ajudar 
em cada bloqueio, ou designando alguém para procurar uma 
solução. A figura a seguir demonstra um possível caso. 
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Figura 13.1: Quadro de Trello para auxiliar uma stand-up dinâmica 


Vale lembrar que o ideal é sempre realizar modelos dinâmicos e 


diferentes de stand-up, não se atendo a uma única forma de 
fazê-las. 





Parking Lot 


O Parking Lot é uma forma de resolver problemas paralelos, 
evitando desvio de assunto. Pode ser aplicado em qualquer tipo de 
reunião, encontro, Inception etc. Seu objetivo é distinguir itens que 
devem ser resolvidos agora e em outro momento (vale lembrar que 
Lean evita resolver problemas agora que podem ser resolvidos no 
futuro). 


De forma geral, separa entre itens que devem ser resolvidos agora, 
resolvidos logo, e não são relevantes e, portanto, não são 
resolvidos. A função da técnica é: "Escutamos você, não vamos 
esquecer, discutiremos assim que possível". As figuras a seguir 
mostram exemplos. 
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Figura 13.2: Exemplo de Parking Lot 1 





Figura 13.3: Exemplo de Parking Lot 2 


O primeiro modelo de Parking Lot simplesmente se utiliza da 
ideia de inserir ideias não adequadas para a reunião em um 
quadro de forma que sejam tratadas em outro momento. O 


segundo modelo faz isso classificando-as por relevância (a 
relevância pode ser para a reunião, stand-up, equipe e 
ferramentas), sendo assim, o card mais central deve ser 
resolvido primeiro. 





Heijoku board 


Gerenciamento visual tem como objetivo permitir que toda a equipe 
entenda e veja o que está acontecendo. Pode ser representado por 
Heijoku boards, kanbans e outros tipos de board abertos para que o 
time tenha visão do que está acontecendo. 


Eles servem para possibilitar ao time uma visualização de tarefas, 
etapas, desenvolvimento, próximos passos ou desempenho. A 
figura a seguir é de um Heijoku board aplicado a etapas de 
desenvolvimento de features via TDD. 
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Figura 13.4: Heijoku board para desenvolvimento de features via TDD (GRÁFICA MOURA 
RAMOS, 2013) 


Speed Boat 


Speed Boat é uma técnica que permite o time visualizar o que é 
importante para o projeto, o objetivo, o que bloqueia e evitar o que é 
negativo a ele. É considerado um jogo de inovacáo divertido. As 
regras do jogo sáo: 


e Desenhe um speed boat em um quadro. 

e O barco é nosso time, nosso jogo, nossa estratégia ou projeto. 
Dê um nome ao barco. 

e Como o objetivo do barco é ir rápido, é importante perguntar o 
que seria uma performance ótima e as condições de 
funcionamento desejáveis. Estas coisas formam o porto. 

e A distância do barco até o porto representa o que devemos 
percorrer para chegar nos nossos objetivos. 

e As âncoras representam os impedimentos e bloqueios do 
barco. Quanto mais fundas elas estão, mais força negativa 
exercem. 

e As setas brancas representam os aspectos positivos 
empurrando o barco. 


Os passos para realizar o jogo são: 


1. Apresentar o jogo para os participantes. Dividir em pares 
geralmente é uma boa ideia. 

. Pensarem nos objetivos e nos fatores positivos do projeto. 

. Apresentarem ao grupo. 

. Em grupos pequenos, pensarem e categorizarem as áncoras. 

. Postar as áncoras no quadro. 

. Priorização coletiva das âncoras no quadro. 

. Discutir um plano de ação para remové-las. 


NOORA ON 


A figura a seguir representa um esquema de Speed Boat: 
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Figura 13.5: Exemplo de Speed Boat (GROSJEAN, 2011) 
Ice Breakers 


Utilize técnicas de Ice Breaker (quebra clima) em reuniões. É uma 
boa forma de ajudar a equipe a relaxar antes de uma Inception, por 
exemplo. Sua função é quebrar o clima desagradável que pode se 
gerar pela presença de diversas pessoas de funções diferentes e 
fazer a equipe relaxar. 


Um exemplo que começamos a usar na Thoughtworks é que as 
pessoas devem se apresentar com nome e pronomes de 
preferência, e depois conversar em um par para apresentar a outra 
pessoa do par sem utilizar pronomes. Outra técnica utilizada aqui é 
que cada membro da equipe tem uma folha com seu nome e uma 
caneta colorida. O objetivo é rodar a sala pedindo que as pessoas 
da sala desenhem uma característica do rosto da pessoa, e depois 
disso os cards são colados na porta da sala de Inception. 
Costumam criar ambientes bastante descontraídos. 


Happiness Radar 


Happiness radar é uma forma de acompanhar como o time se sente 
em relacáo a tecnologia usada, ás pessoas da equipe e aos 
processos utilizados. A ideia é que cada membro marque como se 
sente (feliz, indiferente e triste) em relacáo a cada uma dessas 
áreas. E depois o time discute cada um dos pontos e suas opiniões 
sobre cada coisa. 


Uma das formas de gerar discussáo pós-happines radar é por meio 
da Fun Retro apresentada a seguir. A figura seguinte representa um 
quadro de Happines Radar, e é importante avaliar o nível de 
satisfação da equipe. As colunas representam grau, tecnologia, 
pessoas e processos, respectivamente. 
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Figura 13.6: Exemplo de Happiness Radar 


INSTRUÇ ES 


Para o contexto atual: quão feliz você se sentiu (no geral) em 
relação às áreas apresentadas. 





Fun Retro 


A Fun Retro é uma plataforma que permite ao time realizar uma 
retrospectiva do que passou de forma a identificar o que foi bom, o 
que pode melhorar, o que faltou e as ações que devem ser tomadas. 
A ideia é que cada membro escreva cards, que depois sáo tornados 
públicos, e entáo votados. 


Depois de votados, os mais escolhidos sáo discutidos de forma a 
melhorar o entendimento do time sobre os aspectos e gerar ações 
necessárias. A figura a seguir demonstra um quadro de 
retrospectiva da Fun Retro. 
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Figura 13.7: Exemplo de Fun Retro 
3Ls 


É um método de realizar retrospectivas parecida com o Fun Retro, 
mas com uma ideia um pouco diferente. O nome vem do inglês: 
Learned, Liked, Lacked (aprendeu, gostou, faltou). 


Essa técnica consiste em desenhar em um quadro 3 áreas que 
correspondem a cada um dos Ls, e liberar o quadro para que o time 
cole um número determinado de post-its nas diferentes áreas do 
quadro. Esses post-its são agrupados do ponto de vista de 
proximidade, e depois votados para se realizar uma discussão. 


As discussões podem, e devem, gerar itens de ação que são 
designados a equipes ou indivíduos, de forma que eles se 
responsabilizem por garantir sua solução. Nem todos os itens de 
ação são tarefas técnicas, mas muitas vezes de equipe. 
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Figura 13.8: Quadro de 3Ls 
360 Feedback 


É um sistema de feedbacks que os membros da equipe recebem 
feedbacks anónimos de pessoas com quem trabalham. Pode ser 
usado de forma a funcionar com equipes também. Muitas vezes, 
inclui pessoas além da equipe de desenvolvimento que a pessoa 
está incluída. 


Nesse sistema, sáo levantadas competéncias, problemas e 
sugestões. Os feedbacks são então rankeados, de forma a 
determinar quais devem ser lidados primeiro e quais são mais 
relevantes. Outra técnica é gerar perguntas que devem ser 
respondidas a medida que o tempo passa, como uma forma de 
avaliação de melhora. 


Um bom local para aprender mais sobre é em 


http://www .custominsight.com/360-degree-feedback/what-is-360- 
degree-feedback.asp. 





Roles € Expectations 


É uma ótima atividade para ajudar o time a definir papéis e 
expectativas de casa, uma das funções que os membros da equipe 
devem desempenhar. Um dos principais objetivos é permitir a 
equipe deixar claro o que cada membro deve fazer e, muitas vezes, 
como cada membro deve agir perante o time. 


É uma atividade recomendada quando os papéis dos membros da 
equipe náo estáo claros, ou a saúde da equipe está sendo afetada 
por algum membro que náo está desempenhando seu papel. Muitas 
vezes é uma forma de dar feedbacks com riscos pequenos de 
reações negativas. 


A atividade consiste em uma tabela, conforme as duas figuras a 
seguir, na qual cada membro da equipe descreve o que pensa em 
relação às atividades a serem desempenhadas por cada função 
presente na equipe. No caso das figuras seguintes, temos mais 
espaço para devs, pois a equipe possuía mais devs. A diferença de 
idiomas também é algo interessante da figura, pois pessoas de 
países diferentes estavam presentes, mesmo que remotas, na 
atividade. 








Roles and Expectations Matrix 











DEV 








DEV 


BA 


TL 


PM 


PO 





Responsible for 
Quality, Security, 
Delivery 


link between 
business and 
technical 


+ soft skills, risks 
management, 
coaching 


Dueño de la visión 
del producto 








Qualidade e entrega com 
agilidade, se sentir 
responsável pela troca de 


Depois do PO, pessoa 
que mais conhece 
domínio. Responsavel 
pela historias serem 


Responsável por 
entender os desafios do 
time e busca o melhor 


Responsable por el 
éxito del producto, 
enfoque en valor de 





conhecimento simples e pequenas individual e coletivo negocio. 
Conhecimento do 
A Análise, visáo de a E domínio, previsão 
Delivery y Liderança do time Macro management ao 
negócio de riscos, contato 
principal no Cliente. 





pessoas que desempenham 
multiplos papéis como 
manter a qualidade do 
produto. 


entendimento do 
negócio. ponte entre o 
time e as pessoas de 
negício 


se preocupar com 
o bom andamento 
técnico da equipe 


ajuda a manter o 
time saudável 





visáo do 
produto 









































Responsable por el 
funcionamiento del 
equipo 








Conhece os roadmaps, 
corre atrás de 
desbloqueios. 





Figura 13.9: Roles & Expectations para devs 1 


Roles and Expectations Matrix 











BA 





DEV 


BA 


TL 


PM 


PO 








* Tener una visión enfocada 
en objectivos 

* Curiosidad y deseo de 
trabajar en conjunto con 
BA/PO y otros equipos 





* Visión general de los 
desafíos técnicos y nuestra 
responsabilidad con la 
calidad 

* Disponibilidad para discutir 
temas del producto 





* Soporte con cuestiones 
operacionales 

* Ayuda para garantizar una 
relación saludable entre el 
equipo 





* Visión de los productos 

* Comunicación clara, compartir 
informaciones con el equipo 

* Soporte cuando se van a 
detallar los objectivos en tareas 











TL 




















PM 


* Compromisso com entrega 
de valor 

* Compromisso com os 
cerimonias 





* Ter claramente a visáo do 
negócio 

* Orquestrar as demandas 
do cliente junto ao time 





* Garantir a qualidade 
tecnica 

* Trabalhar para o bom 
funcionamento tecnico 








Trabalhar para o time 


* Ter objetivos claros 
* Trabalhar para a visão do 
produto 








PO 





-Comunica el “que”. 

-Ayuda a escalar 
problemas/bloqueos que tenga el 
equipo. 














-Trabajan en conjunto para 
detallar historias. 

- Alinear objetivos y ayudar a 
construir roadmap/backlog 





-Comunica el “que”. 
-Ayuda a escalar 
problemas/bloqueos que tenga el 
equipo. 














-Trabajan en conjunto para 
entender necesidades del equipo. 
-Ayuda a coordinar sesiones de 
trabajos con el equipo 
(workshops/inceptions) 























Figura 13.10: Roles 8 Expectations para devs 2 








Assim que todos os membros descreverem o que esperam para 
cada função, todos votam nas melhores descrições. As mais 
votadas são combinadas, formando uma nova tabela com todas as 
descrições de deveres e responsabilidades que a equipe espera 
para cada função, como mostra a figura a seguir. 


Roles and Expectations 

















- pessoas que 
desempenham 
multiplos papéis 
como manter a 
qualidade do 
produto, 
desenvolver, 
conversar com 


inovar 
-Tener una visión 


enfocada en 
objectivos 





pessas de negócio, 

















- link between 
business and 
technical 


- Alinear objetivos y 
ayudar a construir 
roadmap/backlog 











- Precisa identificar 
gaps e 
buscar/propor 
soluções, mas 
principalmente 
ajudar o time a se 
desenvolver, ter soft 
skills para identificar 
o que cada 
integrante do time 
quer desenvolver 








- Responsável por 
manter um time 
funcionando de 
maneira saudável, 
entende dos desafios 
do time e busca o 
melhor individual e 
coletivo 








- Responsable por 
el éxito del 
producto, enfoque 
en valor de negocio, 
principal vinculo con 
clientes 


* Visión de los 
productos 

* Alinear objectivos y 
hitos 

* Comunicación clara, 
compartir 
informaciones con el 
equipo 

* Soporte cuando se 
van a detallar los 
objectivos en tareas 











Figura 13.11: Resultado do Roles & Expectations 3 








CAPÍTULO 14 
AnexoB Engines 


Motores (ou engines) sáo programas capazes de integrar diferentes 
elementos de games em um único local, como parte gráfica, 
programação, inteligência artificial, física e objetos do jogo. Porém, 
uma de suas maiores vantagens é a capacidade de exportar jogos 
para os mais diversos formatos. 


Uma outra vantagem de engines é a capacidade de salvar 
elementos (prefabs) bem testados para próximos jogos, diminuindo 
o efeito "reinventar a roda", muito comum em empresas de games. 
Portanto, na hora de escolher qual game engine será utilizada para 
seu projeto, é importante levar em consideracáo tamanho e 
atividade de comunidade de desenvolvimento, e facilidade para 
obter recursos novos, como também o desempenho de cada engine 
no tipo de jogo necessário e a facilidade de se praticar TDD. 


É importante lembrar de que náo tem por que "reinventar a roda" 
cada vez que formos criar um jogo novo. Uma lista de 5 dicas 
importantes na hora da escolha (para mais, acesse 
http://materiais.producaodejogos.com/game-engine-pdj): 


e Rapidez no desenvolvimento, incluindo sistemas de colisões e 
física predefinida. 

e Facilidade para a configuração dos controles de jogadores, 
desde teclados até smartphones (aqui sinto uma grande 
vantagem da Unity). 

e Boa documentação e comunidade ativa. 

e Fácil entendimento dos recursos. 

e Facilidade de distribuição em multiplataformas. 


Alguns exemplos de engines seráo mostrados adiante. 


Unity 


https://unity3d.com/ 


A Unity suporta duas linguagens de programacáo adaptadas para 
games, CH e JavaScript. Alguns jogos da franquia Angry Birds foram 
feitos nela. Permite exportar para a maior parte das plataformas e 
possui versões estáveis para Windows e Mac. Existe uma versão 
gratuita para poucas vendas, e uma versão Pro que possui 
mensalidade. 








Figura 14.1: Editor da Unity. Fonte: https://youtu.be/-eUbcA42-91 


Unreal Engine 


https: //www.unrealengine.com/ 


A Unreal Engine é uma plataforma de jogos famosos, como 
Bordelands, Unreal Tournament, um jogo da franquia do Batman e 
alguns da franquia Tom Clancy. Sua grande vantagem é ser open 
source e possuir seu código disponível em git. 


A partir de 2005, ela passou a ser gratuita para produtos com 
vendas inferiores a 3 mil dólares e, a partir deste valor, 5% de 
royalties por produto e por trimestre. Ela é desenvolvida pela Epic 
Games e suporta C++ e linguagem visual própria. 
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Figura 14.2: Editor da Unreal Engine. Fonte: 
https://forums.unrealengine.com/showthread.php?53230-Unreal-Engine-4-6-Released! 


CryEngine 





https://www.cryengine.com/ 


Desenvolvida pela Crytek para o FarCry, a Ubisoft mantém uma 
engine interna que é uma versão altamente modificada da 
CryEngine, chamada Dunia Engine. Suporta principalmente C++ e 
Lua, mas possui alguma integração com scripts em C#. Exporta 
para a maior parte das plataformas de console e recentemente 
tornou-se gratuita. É uma boa pedida junto com a Unreal e a Unity. 





Figura 14.3: Editor da CryEngine. Fonte: https://www.cryengine.com/features 


Construct2 


https://www.scirra.com/construct2 





Boa engine para quem náo sabe programar, e possui ferramentas 
intuitivas e fáceis de aprender. A engine permite producáo de jogos 
multiplataforma 2D em HTML5. 
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Figura 14.4: Editor da Construct2. Fonte: https: //www.scirra.com/construct2 


Game Maker Studio 


http://www.yoyogames.com/gamemaker 





Uma das engines mais comuns, especialmente entre iniciantes, 
permite exportar para diversas plataformas, como Steam e 
Windows. Porém, para algumas plataformas, é necessário comprar 
módulos adicionais. 


A engine já possui alguns recursos predefinidos de som, música, 
texturas, fontes etc. A versáo gratuita é bem limitada, e a Pro está 
disponível por 149 dólares. 
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Figura 14.5: Editor do Game Maker — Studio. Fonte: edshelf.com/tool/gamemaker-studio/ 


RPG Maker 


Talvez a porta de entrada para a maior parte das desenvolvedoras, 
é uma engine muito comum e simples de usar. É uma clássica 
ferramenta para jogos de RPG. Permite exportar para plataformas 
como Mac OS, Android, ¡OS e HTML5. O padrão de jogos é 
semelhante aos jogos de Pokémon para Gameboy. 
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Figura 14.6: Editor RPG Maker, uma das diversas versões 


Panda3D 


https://www.panda3d.org/ 





É uma game engine open source escrita em Python e C++, 
desenvolvida inicialmente pela Disney. A linguagem na qual a 
engine é pensada para que desenvolvedoras programem é Python. 
A comunidade é pequena, mas bastante ativa. Devido ao uso do 
Python, é uma das engines mais propensas a se utilizar TDD, pois 
há suporte integral da linguagem. 
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Figura 14.7: Editor da Panda3D. Fonte: http://thetechartist.com/?cat=7 


Monogame 


http://www.monogame.net/ 





Náo é exatamente uma engine, mas sim um framework de 
desenvolvimento de jogos criado em cima do antigo framework de 
desenvolvimento de games da Microsoft XNA. Roda em CF e é 
principalmente recomendado para jogos em 2D que necessitem 
bastante desempenho e performance. De todos os listados, é o mais 
fácil para execucáo de TDD. Ótima para jogos de Windows e Mac. 


PyGame 


http://www.pygame.org/lofi.html 


Semelhante ao monogame, mas escrita em Python. É ótima para 
começar e permite forte exploração das capacidades do TDD. Pode 
ser exportada para qualquer formato de computador pessoal, mas 
náo tem bom suporte para mobile. 
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